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

[Alexandre Petrescu <[e-mail]>]

I would like to mention something.

Le 06/12/2019 à 16:09, Joel M. Halpern a écrit :
> Ole, there is no IETF accepted definition of "limited domain".

There is an I-D about limited domains in general.  I agree with it 
partially, towards the positive half.

The limited domain concept was felt needed in other concepts, not just 
SR.  The ULA discussion, to name one of the largest I have seen, relates 
directly to motivate ULA RFC acceptance withing limited domain.

The reason of things working ok in limited domains and not on Internet 
at large was invoked several times when pushing other I-Ds through, even 
though the reason was not called 'limited domain'.

I would go as far as saying that MPLS and IPv6/6lo are _only_ for 
limited domains and will never work for Internet at large.

People joked about the existence of limited domains that cant be seen, 
even though they did not call them that way.

> There is no IETF rough consensus that it is sensible for us to 
> standardize things for "limtied 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.
> 
> 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.

I agree partially.

Alex

> 
> 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
> --------------------------------------------------------------------