Re: [spring] Question about SRv6 Insert function

[Fernando Gont <[e-mail]>]

On 8/9/19 00:32, Ole Troan wrote:
> Fernando,
> 
>>> The takeaway I attempted to highlight is that there is in fact
>>> agreement between 6man and spring on how to proceed, and we are
>>> proceeding as agreed to work on the relevant documents.
>> 
>> I don't really know what the agreement is, other than the implicit 
>> agreement that if you're considering violating an IPv6 standard,
>> you should come to 6man and do a Std Track document that updates
>> the relevant standard...
> 
> if there ever is a corner case were header insertion can be done
> safely, and the issues it creates mitigated, then that should
> certainly not result in an update to the general rule in 8200.

1) As noted in the discussion, there's nothing that you can do with
EH-insertion that you cannot do with encap/decap. I don't see enough
motivation for an update of this sort -- other than "we want to save 40
bytes". In any case, I repeat what many others have already said: It's
on us to find problems on EH-insertion for it to not move forward. There
should first be a strong argument made in favor of it.

2) You cannot "mitigate" the implications of EH-insertion at the
protocol level (attribution of error messages, MTU issues...). The only
possible mitigations are operational, and those quite often fail.

3) While RFC8200 does not employ RFC2119 language (chair's call, not
mine), the statement in RFC8200 is pretty much a MUST. You do need to
update RFC8200. A reader of RFC8200 should now that there are scenarios
in which EH insertion is indeed allowed. Otherwise you end up with two
specs (IPv6 and SRv6) that contradict with each other.

4) I expect that, as co-chair, you'd agree with me that allowing EH
insertion in IPv6 is a major modification/addition. According to our
charter, we don't seem allowed to do that:
The 6man working group is responsible for the maintenance, upkeep, and
advancement of the IPv6 protocol specifications and addressing
architecture. It is not chartered to develop major changes or additions
to the IPv6 specifications.

I'm quite surprised that a few years ago many of you guys wanted to
essentially freeze most work on IPv6, and now you're so open to such a
major and fundamental change.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492