Re: SRH insertion vs encapsulation (Re: Next steps on Extension Header Insertion)

On 05/11/2016 06:41, Tom Herbert wrote:
> On Fri, Nov 4, 2016 at 10:01 AM, Stefano Previdi (sprevidi)
> <sprevidi@cisco.com> wrote:
>>
>>> On Nov 4, 2016, at 5:03 PM, 神明達哉 <jinmei@wide.ad.jp> wrote:
>>>
>>> At Fri, 4 Nov 2016 11:16:34 +0000,
>>> Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
>>>
>>>>> Huh? The segment routing header is far from imaginary.
>>>>
>>>> But what do you deduce is really being specified in the SRH drafts?
>>>>
>>>> In draft-ietf-6man-segment-routing-header-02 it says in section 2.2:
>>>> [...]
>>>> which implies the SRH uses encapsulation, and doesn’t insert an EH
>>>> in the existing header chain.
>>>
>>> My understanding is that actual implementations don't follow what's
>>> written in the draft and do insert an SRH:
>>> https://www.ietf.org/mail-archive/web/ipv6/current/msg24236.html
>>
>>
>> In fact, there are implementations that do what’s written in the draft and also do header insertion for some use cases. The use cases applies to controlled environments where, typically, a EH is inserted at ingress and removed at egress. This is the reality of v6 segment routing implementations used over v6 infrastructure of some operators.
>>
> FWIW, the SR patches currently under review for Linux also do this. I
> did point out the discussions about EH insertion happening on this
> list, but I doubt that we would disallow patches based on that. My
> recommendation was to put a big disclaimer in the documentation and
> allow user to configure it with the assumption they know what they're
> doing.

Which IMNSHO is exactly why we should *not* leave this ambiguous in 2460bis.
(I don't care what people do in the privacy of their own domains. I do care
what is needed for interoperability across the Internet.)

    Brian

> 
> Tom
> 
>> s.
>>
>>
>>
>>> (And my understanding is that the desire of some people to make the
>>> "actual" behavior explicitly standard-compliant is one major
>>> background motivation of why we are having this thread.)
>>
>>>
>>> --
>>> JINMEI, Tatuya
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 