Re: What if? [was Re: Extension Header Insertion]

On 12-Dec-19 00:50, Stewart Bryant wrote:
> 
> 
>> On 11 Dec 2019, at 05:51, Gyan Mishra <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>> 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 
>>
>> 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.

Very true. MPLS allows label stacking. IPv6 does not (intentionally) allow
routing header stacking, but it does allow IPv6-in-IPv6 stacking, a.k.a.
encapsulation.

   Brian

> 
> 
>>
>>
>> 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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 