Understood. Thanks for clarification. Thanks
Gyan On Thu, Jul 27, 2023 at 2:14 AM Robert Raszuk <[email protected]> wrote: > > 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 >> > -- <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
