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 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 >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
