On Thu, Sep 5, 2019 at 11:01 AM Robert Raszuk <rob...@raszuk.net> wrote: > > Hi Ron, > > Nope that is not correct interpretation. Let me try to rephrase it ... > > An IPv6 path contains a source node, a destination node, and transit nodes > Transit nodes belong to network operators which move the packets > When packet enters operator's network it can be encapsulated and new src, dst > and any other elements added to its header - original packet becomes just the > payload > Then new packet (and payload) is send within given domain via transit nodes. > Some transit nodes just do basic IPv6 forwarding, some may see themselves in > the dst field of the packet imposed by ingress node. > If this is the case (when packet is received by segment endpoint) packets are > processed as defined by SRv6 rules. > According to RFC 8200, segment endpoints can insert, change, or delete > extension headers. However, transit nodes that are not segment nodes cannot > insert, change or delete extension headers > Robert,
That's an arbitrary interpretation of RFC8200. Even we were to accept that, it still doesn't address the issues raised for extension header insertion. For instance, I'd invite you do the thought experiment about what happens when an intermediate node inserts a header that causes the packet to exceed the MTU of some downstream forwarding node. There is no robust protocol mechanism to deal with this. The fact that the extension header in question happens to be segment routing doesn't change things in this regard. Tom > Now that is more like what I highlighted few times already ... > > Best, > R.. > > > > On Thu, Sep 5, 2019 at 7:52 PM Ron Bonica > <rbonica=40juniper.....@dmarc.ietf.org> wrote: >> >> 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 <spring-boun...@ietf.org> On Behalf Of Robert Raszuk >> Sent: Thursday, September 5, 2019 10:28 AM >> To: Fernando Gont <fg...@si6networks.com> >> Cc: Suresh Krishnan <suresh.krish...@gmail.com>; 6...@ietf.org; Ole Troan >> <otr...@employees.org>; Joel M. Halpern <j...@joelhalpern.com>; >> spring@ietf.org >> 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 >> >> _______________________________________________ >> 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 > -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
