Re: [spring] Is srv6 PSP a good idea

[Fernando Gont <[e-mail]>]

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
> <[e-mail]> Date: Wednesday, 26 February 2020 at 01:31 
> To: "Pablo Camarillo (pcamaril)" <[e-mail]> Cc: Ron Bonica
> <[e-mail]>, "Joel M. Halpern" <[e-mail]>,
> "[e-mail]" <[e-mail]> Subject: Re: [spring] Is srv6 PSP
> a good idea
> 
> Hi Pablo,
> 
> On Sat, 21 Dec 2019 at 04:38, Pablo Camarillo (pcamaril) 
> <[e-mail]> 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: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1