Robert Responses in-line
Sent from my iPhone > On Sep 20, 2019, at 4:44 AM, Robert Raszuk <rob...@raszuk.net> wrote: > > Hi Gyan, > > > So now talking SRv6 with Ti LFA why is there an EH insertion as we are > > not using mpls LDP and not doing remote LFA and this is not the traditional > > mpls TE FRR. > > TI - stands for Topology Independent ... all other LFA modes rely on > topologies to be able to compute or not the backup path. [Gyan] A few others mentioned this as well the concept of Ti= topology independent feature which seems like a sales pitch buzz word as you always have an underlying IGP so that Ti-LFA “post convergence loop free” using a traffic engineered path bypassing the normal IGP path and LFA alternative next hop backup path next best lowest cost where Ti-LFA is really referring to not necessarily a path that is different from the alternate next hop as it could be any other traffic engineered path which includes the alternative next hop which is the LFA path so then you cannot say then that it’s topology independent. I think how it should be marketed is as since SRV6 and SR-MPLS have the inherent source route capability without having to maintain state in the intermediate nodes it really is a “traffic engineered” TE-LFA is a more accurate marketing buzz word of the LFA used by SR & SRv6. One of the major benefits of SRv6 inherent traffic engineering capabilities is the ability to color traffic engineering each L3 vpn flow natively onto different paths which cannot be easily done with traditional mpls and is a major use case for both enterprises and SPs to move towards SRv6. > > So why insertion/EH modification is needed ... well as I stated before there > are few assets of this and all must be taken into consideration. > > A) In most cases of topologies it may not be required - only in some special > cases you may need to engineer your backup flows and then you either insert > new EH or add another IP encap with such SRH in current SRv6 architecture.. > > B) When you are doing node protection and PLR is adjucent to segment end node > you should fixup such SRH (so modify it on PLR which is not packet > destination) such that the packet will not try to return when LFA routed to > N+1 segment end. > > Why A is option B clearly needs to be fixed or LFA style node protection of > any segment end declared as not supported. > > Of course in bigger picture there any more protection methods to consider and > only specific operator of transit or enterprise is in position to decide what > works best for him. > [Gyan] As an operator with Verizon a Tier 1 SP as well as having a very large internal enterprise SP core - traffic engineering is critical component of our network design and fast reroute path protection alternative next hop capabilities provided by IP LFA and Remote LFA with LDP tunneling from PLR to PQ node is critical to have that line rate optimal throughout hitless make before break pre programmed backup path is a MUST and is really the main business driver justification for any SP or Enterprise to migrate to SRv6 is for that inherent SRv6 traffic engineering 50ms failover to the pre programmed Ti-LFA backup path. Sorry for the long run on sentence 😀 I think we should change the confusing inaccurate name of Ti-LFA to TE-LFA. We definitely need to get this figured out and a solution for intermediate node EH insertion at the PLR node use case for Ti-LFA. Daren You mentioned in one of your threads on this topic that there is some miscommunication or something missing in the spec and that you are working on rectifying with an update. Can you explain how we can fix the issue with intermediate node EH insertion for Ti-LFA use case even though not used in every implementation even though IP LFA is much more widely used then traditional TE FRR where Ti-LFA is providing both capabilities in one feature Ti-LFA with SRv6 so we definitely have to get this figured out with the RFC 8200 violation from a 6MAN perspective. Regards, Gyan > Many thx, > R. > > > > > > > > > > > > > > > >> On Fri, Sep 20, 2019 at 3:06 AM Gyan Mishra <hayabusa...@gmail.com> wrote: >> Hi Robert >> >> I know we have gone through many many lengthy discussions adnosium and I >> know the question has come up a few times and I know you replied back a few >> times related to the service provider use case where we end up with the >> multiple violations of RFC 8200 related to intermediate nodes EH insertion >> as well as many EH insertions occurring and what was mentioned was Ti-LFA. >> So since LFA and Remote LFA are extensions of the IGP providing the 50ms >> failover similar to traditional mpls Fast Reroute capabilities NH & NNH >> link/node/path protection in the legacy TE FRR pce the head end PE LSR adds >> and additional mpls shim for FRR. >> >> With IP LFA and remote LFA used with LDP there are IGP extensions opaque >> LSA’s that provide the pre programmed backup path provided by LFA loop free >> backup path. In that scenario with LDP there is not any additional label >> with LFA but with remote LFA is added for the Remote LFA backup path with >> LDP session protection enabled with targeted LDP session tunnled through the >> RLFA node. >> >> So now talking SRv6 with Ti LFA why is there an EH insertion as we are not >> using mpls LDP and not doing remote LFA and this is not the traditional mpls >> TE FRR. >> >> I am not getting it from a network engineering technical standpoint what the >> use case is and why EH insertion would occur on any intermediate node as >> that even in the legacy mpls TE world its on the ingress LSR PE and for that >> matter in this case the benefit of SRv6 is “native TE” source routing via >> SRH pssi instructions and not maintaining state on the intermediate nodes >> which just do the PSSI and copy the SRH destination rewrite of IPv6 >> destination for the traffic engineered path and then do PSP or USP on the >> egress node of the service provider core. >> >> I designed and manage a fairly large mpls core for Verizon and if their is a >> asic processing penalty hit due to intermediate node EH insertion we don’t >> want it and will stay course with LDP and stick with our path targeting >> SR-MPLS and ditch any ideas of ever going to SRv6. >> >> Thanks in advance for help in clarification of this topic and I think >> understanding the use case would help 6man overall understand the >> justification of the RFC 8200 violations. >> >> Thank you >> >> Gyan Mishra >> Verizon Communications >> Cell 301 502-1347 >> >> Sent from my iPhone >> >>> On Sep 19, 2019, at 3:50 PM, Robert Raszuk <rob...@raszuk.net> wrote: >>> >>> Hi Reji, >>> >>> Notice what it says: " ... explicitly listed intermediate nodes ... " >>> >>> CRH which is used in SRv6+ does not explicitly list intermediate nodes so I >>> do not think the procedures in IPv6 spec apply as the way you interpret >>> them. >>> >>> But I am i no way authoritative ... still learning IPv6 and this thread >>> become great education. >>> >>> An real example where those procedure apply is documented in RFC6554 which >>> does put the addresses explicitly. >>> >>> Many thx, >>> Robert. >>> >>> >>> >>> >>> >>> >>> >>> >>>> On Thu, Sep 19, 2019 at 9:14 PM Reji Thomas <rejithoma...@gmail.com> wrote: >>>> Hi Robert, >>>> >>>> >>I do not know what is the difference between IPv6 Destination Address in >>>> >>the fixed header and "final destination". Where do you carry "final >>>> >>destination" address ? >>>> >>>> See Section 4.4 in RFC 8200. Hope its clear what's the final destination >>>> and the context in which it is used. >>>> >>>> Segments Left 8-bit unsigned integer. Number of route >>>> segments remaining, i.e., number of explicitly >>>> listed intermediate nodes still to be visited >>>> before reaching the final destination. >>>> >>>> Regards >>>> Reji >>>> >>>>> On Thu, Sep 19, 2019 at 10:26 PM Robert Raszuk <rob...@raszuk.net> wrote: >>>>> IPv6 fixed header has only one destination address. So TE midpoint is >>>>> either a packet's destination or not. It can not be both. >>>>> >>>>> I do not know what is the difference between IPv6 Destination Address in >>>>> the fixed header and "final destination". Where do you carry "final >>>>> destination" address ? >>>>> >>>>> Many thx, >>>>> R. >>>>> >>>>>> On Thu, Sep 19, 2019 at 6:17 PM Reji Thomas <rejithoma...@gmail.com> >>>>>> wrote: >>>>>> Hi Robert, >>>>>> >>>>>> >>Well the crux of the matter is that you still need to process all EHs >>>>>> >>at each IPv6 destination which here means each transit node per RFC8200 >>>>>> >>>>>> From RFC 8200 that doesn't seem to be the case or at least as I >>>>>> understand. See Section 4.1 note 1 and note 3. Am I missing something? >>>>>> >>>>>> IPv6 header >>>>>> Hop-by-Hop Options header >>>>>> Destination Options header (note 1) >>>>>> Routing header >>>>>> Fragment header >>>>>> Authentication header (note 2) >>>>>> Encapsulating Security Payload header (note 2) >>>>>> Destination Options header (note 3) >>>>>> Upper-Layer header >>>>>> >>>>>> note 1: for options to be processed by the first destination that >>>>>> appears in the IPv6 Destination Address field plus >>>>>> subsequent destinations listed in the Routing header. >>>>>> >>>>>> note 2: additional recommendations regarding the relative order of >>>>>> the Authentication and Encapsulating Security Payload >>>>>> headers are given in [RFC4303]. >>>>>> >>>>>> note 3: for options to be processed only by the final destination >>>>>> of the packet. >>>>>> >>>>>> Regards >>>>>> Reji >>>>>> >>>>>>> On Thu, Sep 19, 2019 at 9:00 PM Robert Raszuk <rras...@gmail.com> wrote: >>>>>>> >>>>>>>> I disagree. PPSI and PSSI leverages the DOHs in IPv6 architecture >>>>>>>> better. The SRv6+ drafts explain the usecases better FYI. >>>>>>> >>>>>>> Well the crux of the matter is that you still need to process all EHs >>>>>>> at each IPv6 destination which here means each transit node per >>>>>>> RFC8200. That is regardless what any other spec says .... >>>>>>> unfortunately. >>>>>>> >>>>>>> Best, >>>>>>> R. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -------------------------------------------------------------------- >>>>>>> IETF IPv6 working group mailing list >>>>>>> i...@ietf.org >>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> -------------------------------------------------------------------- >>>>>> _______________________________________________ >>>>>> spring mailing list >>>>>> spring@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/spring >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> i...@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> --------------------------------------------------------------------
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
