Peter, I am with you that enabling signalling UPA to the application is up to the operator.
But going with Bruno's concern, the app (say BGP) on vendor X may use UPA in a completely different way that on vendor Y then again on vendor Z. One may invalidate a path with a given next hop for 5 sec the other for 120 sec etc ... as an example. So as suggested I think UPA should not be (in fact I would use normative MUST NOT be) enabled for address families which do not use end to end encapsulation. Thx, R, On Wed, Jul 26, 2023 at 8:41 AM Peter Psenak <ppsenak= [email protected]> wrote: > Hi Bruno, > > please see inline: > > On 26/07/2023 16:38, [email protected] wrote: > > Peter, > > > > please see inline > > > > > >> From: Peter Psenak <[email protected]> > >> Sent: Tuesday, July 25, 2023 10:04 PM > >> > >> Bruno, > >> > >> please see inline: > >> > >> On 25/07/2023 20:58, [email protected] wrote: > >>> Peter, > >>> > >>> Thank for you answer. Please see inline [Bruno] > >>> > >>> > >>>> From: Peter Psenak <[email protected]> > >>>> Sent: Tuesday, July 25, 2023 6:11 PM > >>>> > >>>> Bruno, > >>>> > >>>> On 25/07/2023 14:39, [email protected] wrote: > >>>>> Hi all, > >>>>> > >>>>> IP reachability advertised by IS-IS is often used by other routing > and > >>>>> signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As > >>>>> such, UPA may affect those protocols. > >>>>> > >>>>> Has UPA been presented in other WGs in the routing areas? > >>>>> > >>>>> I believe this would be prudent if not required. > >>>> > >>>> why do you believe so? How is this different to an IGP prefix becoming > >>>> unreachable without UPA? > >>> > >>> [Bruno] Because, at least for IS-IS, this is a protocol extension. > >>> > >>> When receiving: > >>> IP1/32 with metric 0xFE000001 > >>> IP1/24 with metric 10 (covering aggregate) > >>> > >>> Legacy routers will only consider the aggregate for the SPF/RIB > >>> IP1/24 with metric 10 > >> > >> even routers with UPA processing enabled would only use IP2/24 in > >> forwarding. The UPA would only be used to send signal to apps like BGP. > > > > you are correct. > > (I meant legacy node will not see the UPA hence that IP1/32 is > unreachable) > > > >>> > >>> As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible > and used. > >>> > >>> UPA compliant routers will consider the aggregate for the SPF/RIB, > plus they will consider that IP1/32 is unreachable. > >> > >> no, they will NOT consider that IP1/32 is unreachable. > >> > >> UPA is only used to signal the unreachability to apps that are > >> interested. > > > > "apps" are part of the router, in particular BGP. > > So let me rephrase: the BGP protocol on UPA compliant routers will > consider the aggregate for the SPF/RIB, plus they will consider that IP1/32 > is unreachable. > > > >> What the apps do with it is out of the scope of UPA. > > > > Use of UPA have consequences. Some good (advertising loss of > reachability), some bads (forwarding loops for BGP prefixes which are > routed hop by hop). > > I don't think that we can claim the benefits (adopt UPA because it's > useful for e.g. BGP PIC edge) and refuse to talk about the drawbacks. > > ##PP > we basically leave the responsibility to the consumer of the UPA, as the > treatment of the UPA signal an its consequence on the app is app specific. > > But we can clarify that in the draft. > > > > >> > >>> As a result, a BGP route IP2 with BGP Next-Hop IP1 is not feasible and > not used. > >>> > >>> (note that I have assume that the UPA signal is sent to BGP, but this > is the same picture if UPA is only used by BGP PIC Edge) > >>> > >>> > >>> > >>>>> > >>>>> In particular, BGP is (heavily) using reachability of (loopbacks) > >>>>> addresses advertised in IS-IS in order to evaluate the reachability > of > >>>>> BGP routes and compute their preference. > >>>>> > >>>>> If UPA is not interpreted the same ways by all routers, forwarding > loops > >>>>> may occur in a hop by hop routed network. (because different routers > >>>>> would select different paths since they use different information to > >>>>> select their path) > >>>> > >>>> I don't see a problem, please provide an example. > >>> > >>> iPE1 ----- P1 ----- P2 ----- ABR1 ----- P3 ----- ePE2 (IP1) > >>> | > >>> | > >>> ePE3 (IP1) > >>> > >>> > >>> <--------L1--------------------><------------L2-----------> > >>> > >>> ABR1 is L1L2. It advertises, in L1, an aggregate prefix covering > routers in L2. > >>> > >>> > >>> > >>> ePE2 and ePE3 advertise IP1 in BGP. ePE2 is preferred. All nodes have > both BGP paths to IP1. > >>> Traffic to IP1 is IP routed hop by hop from iPE1. > >>> P2 support UPA, P1 does not. > >>> ePE2 fails and ABR1 advertise UPA in level 1. > >>> > >>> > >>> P1 does not support UPA so is unaware of ePE2 failure and keeps > routing IP1 toward ePE2, hence P2. > >>> P2 supports UPA so knows that the ePE2 is down and invalidate BGP > routes using this BGP Next-Hop. Hence P2 routes IP1 toward ePE3. > >>> > >>> --> forwarding loop between P1 and P2 for destination IP1 > >> > >> - UPA processing is optional and disabled by default > >> - typically P1 and P2 would not run BGP at all, so there would be no > >> issues if UPA would be used on iPE1 > >> - if you run BGP hop by hop, you would need to consistently enable UPA > >> on all routers. > > > > Good that we agree on some bad consequences of UPA in case of partial > deployment. > > Can we have a text, if not a section, in the draft to talk about that > partial deployment? > > At least to raise awareness of the potential issues depending the > "application". Ideally, I would have a preference to specifically indicate > the cases that are problematic, but that would imply having a review from > all routing WG. > > Again, I think that the BGP case should be described as this the typical > target that had been discussed on the list to promote UPA, and both IS-IS > and BGP are important for the routing/network. I don't think IS-IS can > shirk responsibility for advertising reachability/unreachability to other > protocols relying on IS-IS. > > > > a first proposal could be > > 6.1 Partial Deployement > > Partial deployment of UPA translates into inconsistent knowledge of the > unreachability of the UPA prefix. For some applications, and in particular > for routing/signaling protocols relying on this (un)reachability, this > leads to inconsistent routing decisions. In some cases this may not be > problematic, in others cases this may be problematic. > > For example with BGP, if a tunnel is used to reach the BGP Next-Hop, > this will not be problematic. On the other hand if the packets are routed > hop by hop, this will lead to forwarding loops. > > Applications and protocols using the UPA information SHOULD consider the > consequences of partial deployment before enabling their use of UPA. > > ##PP > I'm good to include the above in the draft. > > In a nutshell, it is up to the consumer application of the UPA to be > configured correctly if the consistent usage of the UPA across the > network/area is required by the application itself. > > thanks, > Peter > > > > > > Thanks, > > --Bruno > > > >> thanks, > >> Peter > >> > >>> > >>> A priori same thing with BGP PIC edge > > >>> > >>> Thanks, > >>> --Bruno > >>> > >>> ---- > >>>> If an ingress PE decides to switch to an alternate BGP path, how does > >>>> that creates any potential loop? And why all egress PEs would need to > do > >>>> the same? > >>>> > >>>>> > >>>>> This is not considered nor discussed in the draft. Quite the > contrary, > >>>>> draft says that recognition, processing and use of UPA is a local > >>>>> consideration. > >>>> > >>>> yes, and we want to keep it that way. > >>>> > >>>> thanks, > >>>> Peter > >>>> > >>>> > >>>>> > >>>>> I would suggest to at minimum present this draft to IDR and gets the > >>>>> feedback from the IDR WG. > >>>>> > >>>>> --Bruno > >>>>> > >>>> > >>> > >>> Orange Restricted > >>> > ____________________________________________________________________________________________________________ > >>> Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > >>> Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > >>> > >>> This message and its attachments may contain confidential or > privileged information that may be protected by law; > >>> they should not be distributed, used or copied without authorisation. > >>> If you have received this email in error, please notify the sender and > delete this message and its attachments. > >>> As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > >>> Thank you. > >>> > >> > > > > Orange Restricted > > > ____________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme > ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
