Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

[Fernando Gont <[e-mail]>]

Hi, Brian,

On 6/12/19 19:57, Brian E Carpenter wrote:
> On 07-Dec-19 10:22, Fernando Gont wrote:
>> On 6/12/19 17:55, Brian E Carpenter wrote:
>>> Joel,
>>>
[....]
>>
>>
>>
>>>> While there are standards that are designed for specific deployments, 
>>>> they do not to date use that as an excuse to violate existing RFCs.
>>>
>>> I'm not sure that statement is literally 100% correct, because some instances
>>> may well have passed unnoticed or without controversy. SRH insertion
>>> has not tried to pass unnoticed, and has become controversial.
>>
>> My own impression is that it did try to pass unnoticed. 
> 
> draft-voyer-6man-extension-header-insertion-00, a document that I strongly
> criticised, came out March 28, 2017 and its first sentence read "The network
> operator and vendor community has clearly indicated that IPv6 header insertion
> is useful and required." I *really* think that your impression is wrong. This
> has been public for almost 3 years now.

Sorry, what I meant was that "it did try to pass its violation of
RFC8200 unnoticed" -- hence e.g. my comment that even the latest version
does not reference RFC8200.




>> Even the latest
>> rev of the EH insertion draft doesn't even have a reference to RFC8200.
> 
> Well, the current document editor already said that will be fixed.

I would imagine that would be the first thing I would have included in
version -00 of the document, as opposed to try to pretend there are
reasons for which RFC8200 is not really being violated (which seems to
have been the strategy here).



>>>> Hence, as far as I can tell, the assertion that SRv6 is for limited 
>>>> domains does not justify or excuse violating RFC 8200.  And "I want to 
>>>> save some bytes", while very nice, is not a sufficient reason to violate 
>>>> an approved RFC, must less a Full Standard.
>>>
>>> On the other hand, running code in a variety of real and deployed
>>> products is something that we have a long tradition of documenting forEven the latest rev of the        
>>> informational purposes. RFC1094 or RFC3954 for example.
>>
>> Major difference: None of the two protocols you've reference do an
>> outright violation of an IETF standard --- even less an Internet Standard.
> 
> That wasn't my point. (If you want an example that does violate an IS, try RFC1631.)
> 
> My point is that we have often document reality.

I'd have a few comments here:

1) I'm in a way amused that some folks (not you) are more keen to
violate or post a spec that clearly violates a specification, even
without a proper justification, that things' like measurements (RFC7872,
which only got published after dodging way too many bullets), or even
draft-gont-v6ops-ipv6-ehs-packet-drops (probably a good example of
reality being neglected at the IETF). The only explanation that I have
is that in some cases, there's a bit of NIH (Not Invented Here)
syndrome, and/or that there are vendors with big pockets and more power
involved than some of us mere individual participants.

2) The example you reference (RFC1631) is of course a good one. NATs
have been, at the very least, an unavoidable reality. And there's no
nice way to do NAT44. It is what it is. Now, it has been mentioned a few
times here and other lists that the right way to avoid EH-insertion is
encapsulation. I believe that the proponents of EH-insertion could have
tried to take advantage of such advice, and try to build consensus in
that direction. If they explicitly decided to violate the existing
specs, and dismiss the input that was provided by this group, what would
be the point of rubber-stamping their "EH insertion thing" -- "we are a
big vendor, and have the power to publish our spec whether there's
consensus or not?"  -- the fact that they have running code doesn't
obviate the "rough consensus" requirement.

3) Besides the technical arguments against EH insertion (which have been
codified in draft-smith-6man-in-flight-eh-insertion-harmful, I have
asked *lots* of times what's the technical motivation for doing EH
insertion. It boils down to "to save 40 bytes", which doesn't seem to me
as a compelling argument to violate the spec -- even less in a design
that employs 128-bit waypoints and is claimed to be operated in a
limited domain.

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