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

[Tal Mizrahi <[e-mail]>]

Hi Robert,


> Where say in draft draft-quinn-vxlan-gpe do you see such statement that would imply
> that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to any other type
> of extension header further followed by UDP ?


The following text is from Figure 4 in draft-ietf-nvo3-vxlan-gpe:

      Outer IPv6 Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Traffic Class |           Flow Label                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Payload Length        | NxtHdr=17(UDP)|   Hop Limit   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |


There is a similar figure in draft-ietf-nvo3-geneve.

Best regards,
Tal.

From: nvo3 [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:29 AM
To: Tal Mizrahi
Cc: [e-mail]; 6man WG; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Stefano Previdi (sprevidi)
Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header

Hi Tal,

> drafts seem to imply

Where say in draft draft-quinn-vxlan-gpe do you see such statement that would imply that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to any other type of extension header further followed by UDP ?

Thx,
R.


On Mon, May 23, 2016 at 7:50 AM, Tal Mizrahi <[e-mail]<mailto:[e-mail]>> wrote:
Dear Authors of VXLAN-GPE / Geneve,

I am reiterating on this question, as I haven't seen a response yet:

Have you considered the use of Segment Routing with VXLAN-GPE / Geneve? The current VXLAN-GPE / Geneve drafts seem to imply that IPv6 extension headers are currently not supported.

Thanks,
Tal.



>-----Original Message-----
>From: nvo3 [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Tal Mizrahi
>Sent: Tuesday, May 17, 2016 12:09 PM
>To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3-
>[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
>Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; 6man WG; draft-ietf-6man-segment-
>[e-mail]<mailto:[e-mail]>
>Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-
>routing-header
>
>Stefano,
>
>If I understand your point correctly:
>IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, since
>these encapsulations do not currently allow the use of IPv6 extension
>headers.
>
>I wonder if the authors of VXLAN-GPE and Geneve have considered the use of
>segment routing.
>
>Thanks,
>Tal.
>
>
>
>>-----Original Message-----
>>From: Stefano Previdi (sprevidi) [mailto:[e-mail]<mailto:[e-mail]>]
>>Sent: Tuesday, May 17, 2016 10:41 AM
>>To: Tom Herbert
>>Cc: Tal Mizrahi; 6man WG; [e-mail]<mailto:[e-mail]>;
>>draft-ietf-6man-segment-routing- [e-mail]<mailto:[e-mail]>
>>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-
>>header
>>
>>
>>> On May 16, 2016, at 7:10 PM, Tom Herbert <[e-mail]<mailto:[e-mail]>>
>wrote:
>>>
>>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi <[e-mail]<mailto:[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
>>
>>
>>into an outer ipv6 header which makes it a layer-3 encap.
>>
>>
>>> , but I don't think it is explicit as to exact encapsulation format
>>> (I suppose simple ip6ip6 is implied).
>>
>>
>>see section 2.2
>>
>>
>>> But, it
>>> seems like any of several encapsulation techniques could work (VXLAN,
>>
>>
>>I have some problems to understand where to fit an extension header
>>into a vxlan encap…
>>
>>
>>> 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?
>>
>>
>>the draft is about IPv6 extension header and more precisely a new type
>>of the routing extension header defined in rfc2460. That’s the context.
>>
>>
>>s.
>>
>>
>>
>>
>>>
>>> Tom
>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Stefano Previdi (sprevidi) [mailto:[e-mail]<mailto:[e-mail]>]
>>>>> Sent: Monday, May 16, 2016 2:24 PM
>>>>> To: Tal Mizrahi
>>>>> Cc: Ole Trøan;
>>>>> [e-mail]<mailto:[e-mail]>;
>>>>> [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>]
>>>>>>> Sent: Monday, May 16, 2016 2:13 PM
>>>>>>> To: Tal Mizrahi
>>>>>>> Cc: Ole Trøan;
>>>>>>> [e-mail]<mailto:[e-mail]>;
>>>>>>> [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>]
>>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM
>>>>>>>>> To: Ole Trøan; Tal Mizrahi
>>>>>>>>> Cc: [e-mail]<mailto:[e-mail]>;
>>>>>>>>> [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]> Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>
>_______________________________________________
>nvo3 mailing list
>[e-mail]<mailto:[e-mail]>
>https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
spring mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring