From a discussion on the 6man list. Forwarding as requested by the chair as RTGWG owns the TI-LFA design.
Stewart > > >> On Dec 11, 2019, at 03:50, Stewart Bryant <[email protected]> wrote: >> >> >> >>> On 11 Dec 2019, at 05:51, Gyan Mishra <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Warren, >>> >>> Just a thought. >>> >>> There have been other game changer technologies that have come up in the >>> past that really require a lot of collaboration between all WG silo’s >>> namely mpls for starters and now SR which has I am guessing millions poured >>> into by vendors across the globe to get on the band wagon which will be the >>> eventual replacement of mpls. >>> >>> Not to derail my thoughts — SR for example just as with MPLS involved many >>> routing and internet area WGs such as rtgwg, lsr, Bess, teas to name a few. >>> There is a lot of complexity in development and maintaining IETF standards >>> when there are so many very complex inter dependencies between WGs for >>> these types of industry evolution type protocols that pave the way for the >>> future. >>> >>> To that point the topic of TI-LFA which we have talked about in many >>> threads. This draft is owned by rtgwg. I don’t think the authors of this >>> draft being a dependency WG of the WG owner of the main protocol being >>> developed “spring” had knowledge that they were in violation of RFC 8200. >>> I think that is part of the root problem with the process flow in >>> development of a very complex protocol that spans almost every IETF WG. >>> >>> TI-LFA draft: >>> https://tools.ietf.org/pdf/draft-ietf-rtgwg-segment-routing-ti-lfa-01.pdf >>> <https://tools.ietf.org/pdf/draft-ietf-rtgwg-segment-routing-ti-lfa-01.pdf> >>> >>> Bottom of page 3- >>> Thanks to SR, TI-LFA does not require the establishment of TLDP sessions >>> with remote nodes in order to take advantage of the applicability of remote >>> LFAs (RLFA) [RFC7490][RFC7916] or remote LFAs with directed forwarding >>> (DLFA)[RFC5714]. >> >> The TI-LFA draft is data-plane agnostic. >> >> How the draft maps to the dataplane is up to the dataplane designers. >> >> With an MPLS dataplane it all works and conforms to the MPLS architecture. >> >> It is up to the IP dataplane designers to ensure that it conforms to the IP >> dataplane architecture. >> >> >>> >>> >>> I mentioned in on of the threads that MPLS ldp RLFA (remote LFA) requires >>> an MPLS label to be added to ldp tunnel to PQ space end node in a circle >>> topology case where PLR node junction physical bypass LFA node does not >>> exist. Since the backup path programmed is a post convergence path with >>> stateless nodes with SRv6, 6in6 encapsulation at the PLR node is not >>> technically necessary. >>> >>> If the rtgwg new they were in violation of RFC 8200 they would have gone >>> the same path as ldp RLFA and added in the encapsulation into the draft. >> >> As far as I can see the document you cite says nothing about IPv6 and thus >> cannot violate RFC8200, or have I missed something in the text? >> >> You mention the congruence between the repair path and the post convergence >> path. As far as I can see this is loop mitigation in the down case (it says >> nothing about loop mitigation in the up case which is also an important >> problem). Anyway, I stress that I have not yet seen a formal proof that it >> is unconditional loop avoiding as post convergence the packets may not go >> via the PLR and hence may not follow the TI-LFA path. I have asked before >> and have not yet seen such a proof (I apologies if I have missed it) and >> look forward to reading it. >> >> Best regards >> >> Stewart >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> --------------------------------------------------------------------
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
