> where you are forwarding hop by hop routing simultaneously with end to end encapsulation.
That is not the point here. What you said above is mutually exclusive. The issue arise when you are not doing end to end encapsulation as current UPA draft does not preclude using UPA for such networks where routing decision is made at each transit node of the domain or at each segment endpoint. Rgs, Robert On Wed, Jul 26, 2023 at 9:38 PM Gyan Mishra <[email protected]> wrote: > 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. > > 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 <[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. >> >> > >> > > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email [email protected] <[email protected]>* > > > > *M 301 502-1347* > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
