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 <aretana.i...@gmail.com> Sent: 26 August 2020 23:20 To: adr...@olddog.co.uk; The IESG <i...@ietf.org> Cc: pce-cha...@ietf.org; pce@ietf.org; Julien Meuric <julien.meu...@orange.com>; draft-ietf-pce-pcep-flows...@ietf.org Subject: RE: Alvaro Retana's Discuss on draft-ietf-pce-pcep-flowspec-10: (with DISCUSS) 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. > > 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. 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. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
