Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

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

On 01/04/2017 07:14, Robert Raszuk wrote:
> Hi Suresh,
> 
> The fact that encapsulation in new v6 header is optional to me is clearly
> stated in section 4.1 of that document:
> 
>  By default, a local SID bound to the End function does not allow
>       the decapsulation of an outer header.  As a consequence, an End
>       SID cannot be the last SID of an SRH and cannot be the DA of a
>       packet without SRH.
> 
>    o  If the decapsulation is desired, then another function must be
>       bound to the SID 

Sure, any tunnel needs a decapsulator as well as an encapsulator. That's
not news, so what is the problem here? I assume you'd decapsulate in
the last hop router. I don't claim to understand segment routing, so
I can't actually understand the above text. But the text elsewhere
is clear enough that either the original source or the encapsulator
builds the routing header, and that's all we need to know for
2460(bis) compatibility. So why are we still discussing?

    Brian

> (e.g., End.DX6 defined in
>       [I-D.filsfils-spring-srv6-network-programming
> <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.filsfils-spring-srv6-network-programming>]).
> This prevents
>       any unintentional decapsulation by the segment endpoint node.  The
>       details of the advertisement of a SID in the control plane are
>       outside the scope of this document (e.g.,
>       [I-D.previdi-idr-segment-routing-te-policy
> <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.previdi-idr-segment-routing-te-policy>],
>       [I-D.dawra-bgp-srv6-vpn
> <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.dawra-bgp-srv6-vpn>]
> and [I-D.bashandy-isis-srv6-extensions
> <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.bashandy-isis-srv6-extensions>].
> 
> 
> On Mar 31, 2017 13:08, "Suresh Krishnan" <[e-mail]>
> wrote:
> 
>> Hi Robert,
>>
>> On Mar 31, 2017, at 12:56 PM, Robert Raszuk <[e-mail]> wrote:
>>
>> Even if we treat encapsulation in new IPv6 header as only an option ?
>>
>>
>> There are two options listed in the draft with the “either” clause quoted
>> below. Both of them are compliant. In fact, in my not so careful reading, I
>> do not see any text in draft-ietf-6man-segment-routing-header-06
>> <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06> that
>> would be contrary to this text in RFC2460bis.
>>
>> Thanks
>> Suresh
>>
>> P.S.: I am assuming you are using the word option to mean a choice and not
>> an IPv6 option. If not, please clarify.
>>
>>
>> Thx
>> R.
>>
>>
>>
>> On Mar 31, 2017 12:46, "Suresh Krishnan" <[e-mail]>
>> wrote:
>>
>>> Hi Robert,
>>>
>>> On Mar 31, 2017, at 12:01 PM, Robert Raszuk <[e-mail]> wrote:
>>>
>>> Hi Suresh,
>>>
>>> As you requested one of many quotes from the draft which your
>>> clarification to 2460bis directly contradicts with:
>>>
>>> This include either:
>>>
>>>       A host originating an IPv6 packet.
>>>
>>>       *An SR domain ingress router encapsulating a received IPv6 packet
>>>       into an outer IPv6 header followed by an SRH.*
>>>
>>>
>>> Excellent. Thanks for pointing out the exact text. I can confirm that
>>> this text  *is compliant* with the RFC2460bis text.
>>>
>>> Thanks
>>> Suresh
>>>
>>>
>>
>