Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header

[Tom Herbert <[e-mail]>]

On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi <[e-mail]> wrote:
>>it’s all about IP, not layer-2.
>>
>>s.
>
> Right. However, it appears that at least in some cases a VXLAN VTEP will use SR. It certainly may be the case in SFC use cases (see Section 2.3 in draft-ietf-spring-ipv6-use-cases).
>

draft-ietf-6man-segment-routing-header mentions that the packet is
encapsulated, but I don't think it is explicit as to exact
encapsulation format (I suppose simple ip6ip6 is implied). But, it
seems like any of several encapsulation techniques could work (VXLAN,
GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that wants to
do SR is already doing tunneling it seems reasonable to me to only
have one layer of encapsulation. Maybe this should be clarified in the
draft?

Tom

>
>
>>-----Original Message-----
>>From: Stefano Previdi (sprevidi) [mailto:[e-mail]]
>>Sent: Monday, May 16, 2016 2:24 PM
>>To: Tal Mizrahi
>>Cc: Ole Trøan; [e-mail];
>>[e-mail]; 6man WG
>>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-
>>header
>>
>>
>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi <[e-mail]> wrote:
>>>
>>> Hi Stefano,
>>>
>>> Thanks again for the prompt response.
>>>
>>>> 2. the SRH is originated by the ingress node of the SR domain.
>>>>  This is done by encapsulating the packet into a outer
>>>>  (additional) ipv6 header followed by an SRH. This is L3
>>>> encapsulation and no L4 checksum is involved. When the  packet leaves
>>>> the SR tunnel the outer encapsulation  (including the SRH) is removed
>>>> and the packet continues  its journey like nothing happened.
>>>
>>> So VXLAN is off the table?
>>
>>
>>it’s all about IP, not layer-2.
>>
>>s.
>>
>>
>>> It would be worthwhile to clarify this in the draft. If you have a specific
>>encapsulation in mind, it would be great if the draft would specify it.
>>>
>>> Thanks,
>>> Tal.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Stefano Previdi (sprevidi) [mailto:[e-mail]]
>>>> Sent: Monday, May 16, 2016 2:13 PM
>>>> To: Tal Mizrahi
>>>> Cc: Ole Trøan; [e-mail];
>>>> [e-mail]; 6man WG
>>>> Subject: Re: [spring] L4 Checksum and
>>>> draft-ietf-6man-segment-routing- header
>>>>
>>>> Hi,
>>>>
>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi <[e-mail]> wrote:
>>>>>
>>>>> Hi Stefano,
>>>>>
>>>>> Thanks for the responses.
>>>>>
>>>>>> exactly.
>>>>>>
>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes
>>>>>> encapsulation so clearly there’s no L4 involved here.
>>>>>>
>>>>>> s.
>>>>>
>>>>> Two questions:
>>>>> 1. What if the encapsulation is VXLAN? L4 would still be involved, right?
>>>>
>>>>
>>>> See below.
>>>>
>>>>
>>>>> 2. When you say 'assumes encapsulation', does it mean that a host
>>>>> cannot
>>>> send an IPv6 packet with an SRH? The current draft says:
>>>>>
>>>>>  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.
>>>>>
>>>>>
>>>>>
>>>>> Will appreciate if you can clarify that.
>>>>
>>>>
>>>> ok, two cases:
>>>>
>>>> 1. the SRH is inserted at the source.
>>>>  the source originates the packet, the ipv6 header and  the SRH. The
>>>> source computes L4 checksum taking into  account the whole IPv6+SRH.
>>>> Here, theres’ nothing new  compared to rfc2460.
>>>>
>>>> 2. the SRH is originated by the ingress node of the SR domain.
>>>>  This is done by encapsulating the packet into a outer
>>>>  (additional) ipv6 header followed by an SRH. This is L3
>>>> encapsulation and no L4 checksum is involved. When the  packet leaves
>>>> the SR tunnel the outer encapsulation  (including the SRH) is removed
>>>> and the packet continues  its journey like nothing happened.
>>>>
>>>> s.
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Tal.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Stefano Previdi (sprevidi) [mailto:[e-mail]]
>>>>>> Sent: Monday, May 16, 2016 11:59 AM
>>>>>> To: Ole Trøan; Tal Mizrahi
>>>>>> Cc: [e-mail];
>>>>>> [e-mail]; 6man WG
>>>>>> Subject: Re: [spring] L4 Checksum and
>>>>>> draft-ietf-6man-segment-routing- header
>>>>>>
>>>>>>
>>>>>>> On May 15, 2016, at 8:06 PM, [e-mail] wrote:
>>>>>>>
>>>>>>> Tal,
>>>>>>>
>>>>>>>> [Apologies if this issue has been discussed before.]
>>>>>>>>
>>>>>>>> According to draft-ietf-6man-segment-routing-header, an ‘SR
>>>>>>>> Segment
>>>>>> Endpoint Node’ updates the Destination IP address.
>>>>>>>> Therefore, it must also update the Layer 4 Checksum, right?
>>>>>>>>
>>>>>>>> I wonder if there is an upper bound on the size of the SRH.
>>>>>>>> Otherwise, the
>>>>>> L4 Checksum may be located in a pretty deep location.
>>>>>>>> Speaking from a chip vendor’s perspective this may be a problem.
>>>>>>>
>>>>>>> From RFC2460, RH0:
>>>>>>>
>>>>>>>
>>>>>>>    o  If the IPv6 packet contains a Routing header, the Destination
>>>>>>>       Address used in the pseudo-header is that of the final
>>>>>>>       destination.  At the originating node, that address will be in
>>>>>>>       the last element of the Routing header; at the recipient(s),
>>>>>>>       that address will be in the Destination Address field of the
>>>>>>>       IPv6 header.
>>>>>>>
>>>>>>> I would expect SR would work the same.
>>>>>>
>>>>>>
>>>>>> exactly.
>>>>>>
>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes
>>>>>> encapsulation so clearly there’s no L4 involved here.
>>>>>>
>>>>>> s.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ole
>>>>>>>
>>>>>
>>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------