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

[Brian E Carpenter <[e-mail]>]

Joel,

On 07-Dec-19 04:09, Joel M. Halpern wrote:
> Ole, there is no IETF accepted definition of "limited domain".
> There is no IETF rough consensus that it is sensible for us to 
> standardize things for "limtied domains".

That's correct, and that's exactly why the "limited domains" draft
was submitted to the Independent Stream. It is a fact, documented in
that draft, that quite a lot of chartered IETF work is directed at
limited domains.

> 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.
 
> 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 for
informational purposes. RFC1094 or RFC3954 for example.

Regards
   Brian

> 
> Yours,
> Joel
> 
> On 12/6/2019 3:34 AM, [e-mail] wrote:
>> Enno,
>>
>>>>> comply with it. The onus is on them, not on us asking folks to comply
>>>>> with existing standards.
>>>>
>>>> Yes, we have heard your position on this now.
>>>> There is of course a lot more nuance to this argument.
>>>
>>> could you please explain said 'nuance' in more detail?
>>
>> I could try, although I fear it will be a rehash of what has already been said many times already in this debate.
>>
>> The IETF and the Internet architecture has a pugnacious relationship with packet mangling in the network.
>> Steve embodied the Internet architeure principles in the IPv6 protocol suite.
>> The IPv6 architecture consists only of routers and hosts (no middleboxes).
>> Ensuring that routers would not need to process further into the packet than the IPv6 header, and ensure that extension header chains were expensive to parse in hardware. As well as requiring all implementations to support IPsec. Knowing that encryption was the only way to guarantee end to end transparency.
>>
>> Now, contrast that with the "real world", I challenge you to find a service on the Internet where the packet isn't mangled in some way between the two end-points. Be that IPv4 or IPv6.
>>
>> The problems with header insertion on the open Internet are well understood.
>>
>> That's not what is being discussed here though.
>> What is discussed here is what is acceptable to do within a limited domain.
>> To packets that _you_ own, i.e. originate and terminate within a domain where you control all devices.
>>
>> If I own and manage three routers, R1 -- R2 -- R3.
>> You are saying that if R1 sends a packet to R3, it is not allowed to off-load some functions to R2?
>> Going to be difficult to do stuff like service chaining then.
>>
>> When putting in the restrictions in RFC8200, which makes a lot of sense on the open Internet, it was always clear that there could and would be exceptions to this. Those are the ones we are discussing now.
>>
>> Conflating the two use cases and claiming that the arguments for why it's a bad idea on the open Internet also applies to a limited domain, only serves to polarise the debate.
>>
>> My suspicion is that the header insertion argument is a straw-man.
>>
>> Best regards,
>> Ole
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>