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

[Gyan Mishra <[e-mail]>]

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].


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.

I am part of the rtgwg as well as most all the other internet and routing
area WGs.  I don’t mind mentioning to the authors of this draft  the issue
with the RFC 8200 violation.

I can CC you and others on this thread and the 6man and Spring chairs on
the email.  Please let me know if you think I should proceed so we can get
to the root of the eh insertion issue fixed in TI-LFA draft.

Once that is fixed we can get the Spring drafts updated into compliance as
well and finally proceed with PR WGLC.

Kind regards,

Gyan

On Tue, Dec 10, 2019 at 11:30 PM Fernando Gont <[e-mail]> wrote:

> On 10/12/19 20:12, Warren Kumari wrote:
> > On Tue, Dec 10, 2019 at 7:51 PM Brian E Carpenter
> > <[e-mail]> wrote:
> >>
> >> Thanks Darren. I will hold off on the spring draft until we see a new
> version, since several of us are simply repeating ourselves at this point.
> >>
> >> On balance I'm inclined to point a finger at RFC8200:
> >>
> >>>    Each extension header should occur at most once, except for the
> >>>    Destination Options header, which should occur at most twice (once
> >>>    before a Routing header and once before the upper-layer header).
> >>
> >> I now think that either that "should" should be a "must", or there
> >> should be an explicit statement that only one routing header is
> >> allowed. The complexities of multiple routing headers are endless.
> >>
> >> What do others think?
> > [ Of hats, I have none... ]
> >
> > I think that not having RFC2119 language in this section is very
> > unfortunate, and creates a situation where different people read
> > different things into it (and are convinced that their interpretations
> > are clearly the right ones....)
>
> +1 . Although I think RFC8200 should have employed RFC2119 language
> everywhere.
>
>
>
> > I personally think that the spirit behind the Postel principle
> > applies, and that the should is a prohibition against there being more
> > than one, and that if receivers happen to do something sane in this
> > case, it is close to luck, not spec.
>
> +1 on this one. That said, the requirement to process any weird
> combination eventually means lots of unnecessary code and analsys to
> handle weird combinations (such as the one being discussed) that should
> actually never happen.
>
> Thanks,
> --
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant