Subject: Re: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-pcep-flowspec-10: (with DISCUSS)

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 Aug 2020 22:25:18 +0100

Hi Alvaro,

Responding to your Discuss separately from your Comment to get you an answer before the telechat.

> DISCUSS:
>
> §8.7: "it is possible that Flow Specifications will be distributed by BGP as
> well as by PCEP as described in this document...implementations MAY provide a
> configuration control to allow one protocol to take precedence over the other
> as this may be particularly useful if the Flow Specification make identical
> matches on traffic but have different actions."
>
> I understand the need to allow one protocol to take precedence over the other.
>
> The concern I have is that in BGP's distribution model FlowSpecs are forwarded
> to other BGP speakers...which may not also be PCCs.  If PCEP takes precedence,
> and the actions are different, then there might be nodes that take the
> BGP-defined action when not intended to...potentially resulting in unexpected
> forwarding or rate-limiting of the traffic.
>
> Clearly, this issue is related to the different distribution models for the
> information.  If the operator took care of using BGP to distribute FlowSpecs to
> only the PCCs, then this issue wouldn't exist.  I would like to see some text
> that provides guidance when using both distribution mechanisms.

This is a worthy Discuss!

My understanding of the way that BGP FlowSpecs work is that it is not required that they be identical at different BGP routers. Indeed, part of the point is that different flows are treated differently at different routers.

Furthermore, before even considering PCEP, we need to recall that FlowSpecs can be installed by BGP or by direct user configuration at individual routers.

Now, when we look at PCEP installing FlowSpecs, they apply only on individual routers. They are used to classify traffic into LSPs at the head end of those LSPs (these are TE LSPs and not LDP LSPs). The FlowSpecs only have meaning at the head end of the LSPs and to consider distributing them to other nodes would be chaotic and wrong.

Whether the behaviour of the whole network is "unexpected" when different FlowSpecs are installed by different mechanisms is dependent on how carefully one is managing the system. If, for example, you have a mixed IP/MPLS network that used MPLS-TE, then you might consider that the TE-LSPs cause traffic to diverge from the shortest paths and that that fact could have unexpected consequences for how traffic is balanced in the network. Furthermore, if the TE-LSP doesn't go all the way to the destination, you can get tromboning and all sorts of undesirable effects. Yet, carefully managed TE is highly popular.

What this spec does (and all that this spec does) is provide a mechanism for the head end of LSPs to know what traffic to put on those LSPs. Currently this is done using any number of proprietary configuration tools. This offers a standardised approach that melds with the mechanism used to configure the LSPs.

FWIW, over the years we have been working on this document, I have repeatedly thought that we made a mistake to mention the term FlowSpec. The problem with the term is it makes people think "BGP" too readily. In the end, however, the mechanism for implementing packet filters for BGP and for directing traffic to LSPs is all in one place in all the implementations, so the common use of the term is practical.

Best,
Adrian

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 26 Aug 2020 22:19:47 +0000

On August 26, 2020 at 5:25:20 PM, Adrian Farrel wrote:

Adrian:

Hi!

...
> > The concern I have is that in BGP's distribution model FlowSpecs are
> > forwarded to other BGP speakers...which may not also be PCCs. If PCEP
> > takes precedence, and the actions are different, then there might be
> > nodes that take the BGP-defined action when not intended to...potentially
> > resulting in unexpected forwarding or rate-limiting of the traffic.
> >
> > Clearly, this issue is related to the different distribution models for
> > the information. If the operator took care of using BGP to distribute
> > FlowSpecs to only the PCCs, then this issue wouldn't exist. I would like
> > to see some text that provides guidance when using both distribution
> > mechanisms.
>
> My understanding of the way that BGP FlowSpecs work is that it is not
> required that they be identical at different BGP routers. Indeed, part of
> the point is that different flows are treated differently at different
> routers.

Right.  That is not my concern; I wasn't clear enough.

As you know, there are multiple ways of setting up distribution of
FlowSpec in BGP.  One way is to have point-to-point BGP sessions from
a central box to specific routers where the actions are to be applied
-- limiting the distribution to just those BGP speakers.  In this
case, the FlowSpecs/Actions will likely be different (as you
describe).

I'm not concerned about that case.

Let me try again.  rfc5575bis says this:

   From an operational perspective, the utilization of BGP as the
   carrier for this information allows a network service provider to
   reuse both internal route distribution infrastructure (e.g., route
   reflector or confederation design) and existing external
   relationships (e.g., inter-domain BGP sessions to a customer
   network).

By reusing the "internal route distribution infrastructure", the
FlowSpecs are advertised, for example, from the originator to a route
reflector to its clients -- and maybe even further (consider a
hierarchical RR deployment).  Note that this type of distribution is
"normal" BGP, not specific to FlowSpec.

In this case, the FlowSpecs are the same everywhere -- there may not
be traffic that matches, but they are the same (modulo local policy).

Assume distribution through a RR, and locating the LSP headend at the
RR (= PCC).  If traffic comes into the network through the clients, it
will first be matched against the BGP FlowSpec...even if PCEP has
precedence over BGP at the RR/PCC.  IOW, the traffic would first be
subject to the action advertised by BGP before the PCC can act on it.

Is this explanation clearer?

Note that in some cases this type of setup may be what the operator
wants: maybe the intent is to rate limit (some of) the traffic (at the
client using BGP) and then let the headend put it in a specific LSP
(using PCEP).

I think this document doesn't cover the potential downside of using
different distribution models. It might not be evident to everyone
that the BGP information may be propagated further.

Thanks!

Alvaro.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 27 Aug 2020 11:30:40 +0100

Hi Alvaro,

Thanks for iterating on this.

I think it is not a 'potential downside' that the BGP FlowSpecs may be propagated further than the PCEP ones. I think it is highly functional. The PCEP FlowSpec is intended to apply only at the head end of the LSP. It is not about network planning, but out processing on a single node that is the head end of the LSP.

Looked at another way: why was the LSP set up? Presumably the operator saw the need to tunnel traffic from one point in the network to another. That assumes that the traffic is arriving at that head end (because otherwise, the LSP is a bit of a waste of time). All this document does is tell the head end what traffic to put on the LSP, and (by omission) what traffic to continue to route using other means. If changes to the routing system (whether through BGP with or without FlowSpecs, or through IGPs) mean that the traffic never reaches the head end of the LSP, that is perfectly OK as far as this work is concerned. Of course, the operator might be annoyed that they set up an unused LSP, but they are also in control of the routing system, so they should work it out.

I think there are three points we can work on to add to the document:
1. PCEP-installed FlowSpecs MUST NOT be redistributed to other routers using BGP.
2. PCEP-installed FlowSpecs are intended to be installed only at the head-end of the LSP to which they direct traffic. It is acceptable (and potentially desirable) that other routers have FlowSpecs that match the same traffic but direct it onto different routes or to different LSPs.
3. Note that changes to the wider routing system (such as the distribution and installation of BGP FlowSpecs, or fluctuations in the IGP link state database) might mean that traffic matching the PCEP FlowSpec never reaches the head end of the LSP at which the PCEP FlowSpec is installed. This may or may not be desirable according to the operator's traffic engineering and routing policies, but it is not an effect that this document seeks to address.

BTW - a second issue arises from various discussions which had escaped us before. 5575bis makes a change from 5575 such that only one instance of any type of flow specification component can now be present in a FlowSpec. This makes our life a lot easier and we can tidy the document accordingly.

Best,
Adrian

-----Original Message-----
From: Alvaro Retana <[email-masked]> 
Sent: 26 August 2020 23:20
To: [email-masked]; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; Julien Meuric <[email-masked]>; [email-masked]
Subject: RE: Alvaro Retana's Discuss on draft-ietf-pce-pcep-flowspec-10: (with DISCUSS)

Adrian:

Hi!

...

Thanks!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 27 Aug 2020 06:06:48 -0700

On August 27, 2020 at 6:30:41 AM, Adrian Farrel wrote:

Adrian:

Hi!

> 1. PCEP-installed FlowSpecs MUST NOT be redistributed to other routers

Just to be clear, redistributing PCEP FS was never the intent.

Are there cases where PCEP information is redistributed into a routing
protocol?  If not, then I don't think this first point is necessary.

> 2. PCEP-installed FlowSpecs are intended to be installed only at the
> head-end of the LSP to which they direct traffic. It is acceptable (and
> potentially desirable) that other routers have FlowSpecs that match the
> same traffic but direct it onto different routes or to different LSPs.

ok

> 3. Note that changes to the wider routing system (such as the distribution
> and installation of BGP FlowSpecs, or fluctuations in the IGP link state
> database) might mean that traffic matching the PCEP FlowSpec never reaches
> the head end of the LSP at which the PCEP FlowSpec is installed. This may
> or may not be desirable according to the operator's traffic engineering and
> routing policies, but it is not an effect that this document seeks to
> address.

That is what I'm looking for: a mention of the potential...

Thanks!

Alvaro.