Hi Fernando, adding to my own comment and to be more specific:
The existing RFCs are very clear in their wording that the node identified in the Destination Address field of the IPv6 header is free to do whatever it desires with the packet it just received. After all, the packet was addressed specifically to that node. These nodes are called segment endpoint nodes in SRv6. Only nodes that are *NOT* identified in the DA are prohibited from making any changes. This should be very clear, even if you seem to wish that IPv6 had been defined differently. Best, Dirk On Wed, Feb 26, 2020 at 5:45 PM Dirk Steinberg <d...@lapishills.com> wrote: > Hi Fernando, > > I am amazed to read that you believe that you > have the sole power to retroactively re-interpret the > wording of existing RFCs and make changes to said > wording to give documents that have existed for > many years (RFC2460 more than 20 years) a > new meaning. > > Interesting. > > Where can I obtain such superpowers? > > Best, > Dirk > > On Wed, Feb 26, 2020 at 4:36 PM Fernando Gont <ferna...@gont.com.ar> > wrote: > >> On 26/2/20 11:01, Pablo Camarillo (pcamaril) wrote: >> > Hi Mark, >> > >> > Thank you for your feedback. Please see inline [PC1]. >> > >> > Cheers, Pablo. >> > >> > -----Original Message----- From: Mark Smith >> > <markzzzsm...@gmail.com> Date: Wednesday, 26 February 2020 at 01:31 >> > To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com> Cc: Ron Bonica >> > <rbon...@juniper.net>, "Joel M. Halpern" <j...@joelhalpern.com>, >> > "spring@ietf.org" <spring@ietf.org> Subject: Re: [spring] Is srv6 PSP >> > a good idea >> > >> > Hi Pablo, >> > >> > On Sat, 21 Dec 2019 at 04:38, Pablo Camarillo (pcamaril) >> > <pcama...@cisco.com> wrote: >> >> >> >> Hi Ron, >> >> >> >> I guess we are making some progress here but going in some circles. >> >> So far we have moved from “this violates RFC8200” to “there are no >> >> use-cases or benefits” to “this is complex for an ASIC” to “what is >> >> the benefit again” and now back to “this is complex for an ASIC”. >> >> >> > >> > As far as I know, the next header field in both the IPv6 fixed >> > header and in extension headers is immutable while the packet is >> > travelling within the network, as is the payload length field in the >> > IPv6 base fixed header. >> > >> > [PC1]: Did you just make this up? ;-) RFC8200 does not talk about >> > mutability. >> > >> > Nothing in RFC 8200 modifies those fields while the packet is in >> > flight between the packet's original source and final destination, >> > nor is there anything in RFC 8200 that specifies how to do those >> > modifications and any other discussion about the consequences and >> > considerations when doing so. >> > >> > [PC1]: I disagree with you. As a matter of fact RFC8200 allows the >> > deletion of an extension header at a node identified in the >> > destination address of the packet (page 8 paragraph 2). >> >> Unfortunately, the amount of creativity that has been applied during the >> last few years when it comes how to read RFC2460 and RFC8200 has meant >> that we have had to work harder and harder to clarify the wording in >> RFC2406 and RFC8200 for folks to understand and recognize what has >> always been the specification and intent of IPv6. >> >> I have made yet another attempt to clarify the text here: >> https://www.rfc-editor.org/errata/eid5933 >> >> I'd hope that the submitted errata is processed, the existing spec is >> honored and respected, and folks submit a formal specification update if >> they mean to change IPv6 -- as opposed to try to circumvent the spec for >> the n-th try. >> >> Thanks, >> -- >> Fernando Gont >> e-mail: ferna...@gont.com.ar || fg...@si6networks.com >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> >> _______________________________________________ >> 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
