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

["Larry Kreeger (kreeger)" <[e-mail]>]

I agree with Robert and Jesse. - Larry

From: Jesse Gross <[e-mail]<mailto:[e-mail]>>
Date: Monday, May 23, 2016 at 1:19 PM
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>, Tal Mizrahi <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 6man WG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Stefano Previdi (sprevidi)" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header
Resent-From: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-To: Larry Kreeger <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Monday, May 23, 2016 at 1:20 PM

I agree that I don’t believe that there is anything in these drafts that precludes the use of extension headers or segment routing – IP is simply the layer underneath that these protocols are building on. The figures are definitely just examples – they also show outer Ethernet headers, which is not a requirement.

I wouldn’t want to add text specifically stating that extension headers are permissible. It seems like that could lead to similar questions in the future where one might wonder if other features of IP are allowed because one is explicitly listed and others are not, etc. In my opinion, the drafts are about as clear as they can be on this point.

Jesse

On 5/23/16, 1:09 AM, "[e-mail]<mailto:[e-mail]> on behalf of Robert Raszuk" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

Hi Tal,

> In order to avoid ambiguity, it would be great if the
> authors could explicitly mention that IPv6 extension
> headers are permitted.

Well the drafts are complaint to RFC2119 (normative reference) so unless the text excludes elements with MUST/MUST NOT - everything else defined in the building blocks they (re)use is permitted.

However as you say perhaps for clarity what could be added to those drafts is a normative reference to IPv4 and IPv6 base RFCs.

Best,
R.


On Mon, May 23, 2016 at 9:54 AM, Tal Mizrahi <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

That makes sense.
However, in this case the figures may be a bit confusing WRT the possible existence of extension headers. This confusion is what led to the discussion in this thread about whether segment routing is possible with VXLAN/VXLAN-GPE/Geneve encapsulations.

In order to avoid ambiguity, it would be great if the authors could explicitly mention that IPv6 extension headers are permitted.

Regards,
Tal.

From:[e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:47 AM

To: Tal Mizrahi
Cc: [e-mail]<mailto:[e-mail]>; 6man WG; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Stefano Previdi (sprevidi)
Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header

Hi Tal,

Indeed .. I saw the figures, but figures are non normative in any draft/rfc unless text below specifically spells it out.

For example from vxlan-gpe:

"When the outer IP header is IPv4, VTEPs MUST set the DF bit."

Besides it is pretty challenging to add animation to the current draft formats to illustrate all possibly allowed field values/combinations in any figure :)  Figures just illustrate one use example.

To me the current specs permit any value of IPv6 NxtHdr field as permitted in both encapsulations.

Best,
Robert.


On Mon, May 23, 2016 at 9:35 AM, Tal Mizrahi <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:29 AM
To: Tal Mizrahi
Cc: [e-mail]<mailto:[e-mail]>; 6man WG; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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