Hi Gyan, Always a pleasure! See inline, please let me know if you have got any other questions.
Cheers, Jeff On Sep 20, 2019, 10:20 AM -0700, Gyan Mishra <hayabusa...@gmail.com>, wrote: > > > Sent from my iPhone > > On Sep 19, 2019, at 10:43 PM, Jeff Tantsura <jefftant.i...@gmail.com> wrote: > > > Gyan, > > > > IPFRR doesn’t use/need any IGP extensions and is local to the device > > computing LFA. > > As RTGWG chair - I welcome you to read a number of rather well written RFCs > > on the topic we have published in RTGWG over the last 7 years. > > Pay attention on how LFAs are computed, this would clarify your question as > > to why there’s no need for additional imposition as well as why LFA > > provides partial coverage. > > There’s also TI-LFA draft that explains how TI-LFA is computed and why it > > relies on additional imposition if LFA is unavailable. > > > > Regards, > > Jeff > > > > Thanks you Jeff! > > I am part of the RTGWG and will definitely read through all the RFCs as well > as Ti-LFA draft I detail. > > I read through RFC 5286 IP LFA the LFA algorithm uses the underlying IGP to > for alternative loop free next hop for link and node protection but since > it’s the algorithm runs locally to build the “backup” path pre programmed it > does not require IGP extensions. > IP LFA is similar algorithm to the CISCO proprietary EIGRP topology loopfree > feasible successor backup paths. Am I stating that correctly reason why LFA > does not rely on IGP extensions. [jeff] IP LFA relies on the fact that in LS routing protocols, all routers in area/level share same LSDB, hence LFA's can be computed, DUAL (EIGRP) has some similarities, you could further read RFC7868 (Feasibility Condition) > > RFLA RFC 7490 - so I had a question - always wondered about - so RLFA is used > when a LFA path does not exist so a ldp tunnel is built to the PQ node for > backup RLFA pre programmed path to get built. [jeff] it is a local policy matter, in the implementation I worked on, this was the default behavior. > So when that LDP tunnel is build an extra mpls shim is added to the label > stack. Is that correct for RLFA backup paths. Is it just a single shim or > multiple to do the RLFA LDP tunneling. [jeff] this is a single MPLS(transport) label > > I read through the Ti-LFA draft [jeff] we have adopted the draft as wg document, it has been updated, please read draft-ietf-rtgwg-segment-routing-ti-lfa-01 > > https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-ti-lfa/ > > So Ti-LFA uses loop free uses a traffic engineered IGP independent topology > independent path that is desired with SR-MPLS or with SRv6 uses the EH SRH > SID list for the pre programmed backup path. So an additional EH insertion > has to occur on the ingress PE to the SR or SRV6 domain. [jeff] No, the insertion is happening at the PLR (point of local repair) and is local to the PLR, if a backup path is instantiated at head-end/ingress PE, we are talking about “path protection”, e.g. - when head-end desired to switch over to a backup path it does so without help of any intermediate nodes. > I have to read through more carefully but I am not seeing how an > intermediate node would require EH insertion since that function is always on > the source node head end of the traffic engineered path. [jeff] see my previous comment, it is indeed the intermediate node (PLR) that computes LFA and if PQ node is not available thru shortest path (think ring topology) it has to impose additional piece of data-plane information (MPLS labels/EHs) that would be used by intermediated nodes to get to the PQ node. > > Regards, > > Gyan > > On Sep 19, 2019, at 18:06, 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 > > > > > > > > > <rejithomas...@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 > > > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > > > 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
