Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

[Ron Bonica <[e-mail]>]

Robert,

I think that I can summarize what you are saying as follows:


  *   An IPv6 path contains a source node, a destination node, and transit nodes
  *   Some transit nodes are also segment endpoints. Segment endpoints are identified by either of the following:
     *   The initial value of the IPv6 address
     *   An entry in the segment list of the Routing header
  *   According to RFC 8200, segment endpoints can insert, change, or delete extension headers. However, transit nodes that are not segment headers cannot insert, change or delete extension headers

Have I read your email, below, correctly? Is this what you are actually saying?

                                                                  Ron

From: spring <[e-mail]> On Behalf Of Robert Raszuk
Sent: Thursday, September 5, 2019 10:28 AM
To: Fernando Gont <[e-mail]>
Cc: Suresh Krishnan <[e-mail]>; [e-mail]; Ole Troan <[e-mail]>; Joel M. Halpern <[e-mail]>; [e-mail]
Subject: Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)


3) Now there's at least one I-D in spring that ignores RFC8200, and
proposes EH-insertion as if it was allowed, essentially circumventing
RFC8200, and IETF consensus.

Incorrect. RFC8200 makes it black on white clear that insertion, deletion and mangling is allowed in IPv6 if destination is yourself in the packet's IPv6 outer header.

So functions to insert SRH or delete it discussed in SPRING DO NOT violate anything.

Remember - in SRv6 you *change* IPv6 dst at each end of segment. So each SR segment node can legally  do whatever it needs with EH.

Is this clear enough?

- - -

There is other individual document in 6man proposing a solution for FRR in IPv6 which goes beyond the above. But it in no way that should impact base specs. As written base specs can be used 100% legally according to RFC8200 as it stands today.

Now if 6man response to proposl of SRv6 use case for FRR with TI-LFA will state "IPv6 was not designed for that" - I am fine. It will make IPv6 deployments for sure much more robust. It may even help end to end principle shine again and get all of your end IPv6 compute and set-top boxes full open to global hackers.

Thx,
R.


Juniper Business Use Only