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

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

Robert,

Actually this was thoroughly discussed (mainly with Stefano I think)
and these texts in draft-ietf-6man-segment-routing-header-06 were
carefully designed to be compatible with both RFC2460 and RFC2460bis:

Section 2.3.1:
>  The outer header with the SRH is no different from any other
>  tunneling encapsulation mechanism and allows a network operator to
>  implement traffic engineering mechanisms so to efficiently steer
>  traffic across his infrastructure.
 
Section 5.1:
>  A Source SR Node can be any node originating an IPv6 packet with its
>  IPv6 and Segment Routing Headers.  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.

I suppose we need expert review of the routing header itself, but
for me there is simply no issue about compatibility with 2460(bis).

(draft-voyer-6man-extension-header-insertion is a quite different
conversation and we should not confuse the two. That would be FUD.)

Regards
   Brian

On 01/04/2017 06:56, Robert Raszuk wrote:
> Even if we treat encapsulation in new IPv6 header as only an option ?
> 
> 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
>>
>>
>