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
