Hi Gyan, Please see inline.
From: Gyan Mishra <hayabusa...@gmail.com> Sent: Thursday, July 27, 2023 6:38 AM To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com> Cc: Peter Psenak <ppse...@cisco.com>; lsr <lsr@ietf.org> Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce Hi Bruno Can you give an example of an application or scenario where you are forwarding hop by hop routing simultaneously with end to end encapsulation. 1. As already replied by Robert, the point if not about having both at the same time. The point is to clarify the applicability of UPA. And most importantly, when UPA should not be used. 2. To reply to your question, an ISP could/would typically forward hop by hop the IPv4 Internet traffic. It could also uses encapsulation for IPv6 Internet (e.g. 6PE) and VPN services. (And I’m pretty certain that this is not a theoretical only scenario 😉 ) Regards, --Bruno So the end to end encapsulation would be MPLS, SR-MPLS or SRv6 and both global table routing and L3 VPN instances and even simultaneously all three would be end to end encapsulation. I was trying to imagine a scenario where you have hop by hop forwarding which would be IP forwarding without MPLS or L3 VPN just straight IP forwarding. If you are doing global table IPv6 that would be the one possible scenario and with that in parallel have MPLS / SR-MPLS as ships in night during a migration phase. RSVP-TE if you throw into the mix that is also same end to end encapsulation over LSP MPLS dataplane. In an end state network I can’t see how you would have two different data planes simultaneously. In the DC you could have IP fabric hop by hop and migrating to NVO VXLAN or GENEVE end to end encapsulation. Anytime you have an overlay such as VPN or NVO are all end to end encapsulations. So it’s few and far between scenarios with hop by hop which would be any scenario using vanilla IP fabric single tenant and no overlay. Thoughts? Gyan On Wed, Jul 26, 2023 at 10:38 AM <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote: Peter, please see inline > From: Peter Psenak <ppse...@cisco.com<mailto:ppse...@cisco.com>> > Sent: Tuesday, July 25, 2023 10:04 PM > > Bruno, > > please see inline: > > On 25/07/2023 20:58, > bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote: > > Peter, > > > > Thank for you answer. Please see inline [Bruno] > > > > > >> From: Peter Psenak <ppse...@cisco.com<mailto:ppse...@cisco.com>> > >> Sent: Tuesday, July 25, 2023 6:11 PM > >> > >> Bruno, > >> > >> On 25/07/2023 14:39, > >> bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> 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. > > > 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. 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 Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
