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

From: Tal Mizrahi <[email-masked]>
Date: Sun, 15 May 2016 10:04:35 +0000

Hi,

[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.

Thanks,
Tal Mizrahi.

---

From: [email-masked]
Date: Sun, 15 May 2016 20:06:35 +0200

Tal,

> According to draft-ietf-6man-segment-routing-header, an ‘SR Segment Endpoint Node’ updates the Destination IP address.
> 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.

Cheers,
Ole

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 16 May 2016 06:21:25 +0000

Hi Ole,

Thanks for the prompt response. 

It would be helpful if the authors added a comment about the L4 Checksum to the current draft, even though this functionality was defined in RFC 2460.

Best regards,
Tal.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Sunday, May 15, 2016 9:07 PM
>To: Tal Mizrahi
>Cc: [email-masked]; [email-masked];
>6man WG
>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-
>header
>
>Tal,
>
>> According to draft-ietf-6man-segment-routing-header, an ‘SR Segment
>Endpoint Node’ updates the Destination IP address.
>> 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.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 16 May 2016 08:58:53 +0000

> On May 15, 2016, at 8:06 PM, [email-masked] wrote:
> 
> Tal,
> 

exactly.

Moreover, draft-ietf-6man-segment-routing-header assumes encapsulation so clearly there’s no L4 involved here.

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 16 May 2016 09:00:49 +0000

> On May 16, 2016, at 8:21 AM, Tal Mizrahi <[email-masked]> wrote:
> 
> Hi Ole,
> 

please read carefully draft-ietf-6man-segment-routing-header.

The model described assumes encapsulation of the original packet into an outer ipv6 header followed by a SRH. When the packet leaves the SR tunnel there are no traces of segment routing whatsoever. L4 clearly does not apply here, it’s basic tunneling.

s.

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 16 May 2016 09:04:00 +0000

Hi Stefano,

Thanks for the responses.

>so clearly there’s no L4 involved here.

Two questions:
1. What if the encapsulation is VXLAN? L4 would still be involved, right?
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.

Thanks,
Tal.

>From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
>Sent: Monday, May 16, 2016 11:59 AM
>To: Ole Trøan; Tal Mizrahi
>>> 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.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 16 May 2016 11:13:12 +0000

Hi,

> 1. What if the encapsulation is VXLAN? L4 would still be involved, right?

See below.

> 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.

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 16 May 2016 11:19:46 +0000

Hi Stefano,

Thanks again for the prompt response.

>   its journey like nothing happened.

So VXLAN is off the table? 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.

>Sent: Monday, May 16, 2016 2:13 PM
>To: Tal Mizrahi
>Cc: Ole Trøan; [email-masked];
>[email-masked]; 6man WG
>>> Moreover, draft-ietf-6man-segment-routing-header assumes
>>> encapsulation so clearly there’s no L4 involved here.
>>>
>>> s.
>>
>> Two questions:
>> 2. When you say 'assumes encapsulation', does it mean that a host cannot
>send an IPv6 packet with an SRH? The current draft says:
>>
>>> Cc: [email-masked];
>>> [email-masked]; 6man WG
>>> Subject: Re: [spring] L4 Checksum and
>>> draft-ietf-6man-segment-routing- header
>>>
>>>
>>> Moreover, draft-ietf-6man-segment-routing-header assumes
>>> encapsulation so clearly there’s no L4 involved here.
>>>
>>> s.
>>>
>>>
>>>>
>>>> Cheers,
>>>> Ole
>>>>
>>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 16 May 2016 11:24:06 +0000

> On May 16, 2016, at 1:19 PM, Tal Mizrahi <[email-masked]> wrote:
> 
> Hi Stefano,
> 
> 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.
> 
>

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 16 May 2016 11:32:20 +0000

>it’s all about IP, not layer-2.

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).

>Sent: Monday, May 16, 2016 2:24 PM
>To: Tal Mizrahi
>>> 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.
>>
>> 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.
>>
>>
>>>  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.
>>>
>>> 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.
>>>>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 16 May 2016 10:10:03 -0700

> 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

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 17 May 2016 07:41:02 +0000

> On May 16, 2016, at 7:10 PM, Tom Herbert <[email-masked]> wrote:
> 
> 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

I have some problems to understand where to fit an extension header into a vxlan encap…

> have one layer of encapsulation. Maybe this should be clarified in the

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.

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 17 May 2016 09:08:32 +0000

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.

>Sent: Tuesday, May 17, 2016 10:41 AM
>To: Tom Herbert
>Cc: Tal Mizrahi; 6man WG; [email-masked]; draft-ietf-6man-segment-routing-
>[email-masked]
>>> 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).
>>>
>>
>> , 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
>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
>>
>>>
>>>
>>>> Cc: Ole Trøan;
>>>> [email-masked];
>>>> [email-masked]; 6man WG
>>>>>> 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.
>>>>>
>>>>>> Cc: Ole Trøan;
>>>>>> [email-masked];
>>>>>> [email-masked]; 6man WG
>>>>>> the source originates the packet, the ipv6 header and  the SRH.
>>>>>> The source computes L4 checksum taking into  account the whole
>IPv6+SRH.
>>>>>> 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.
>>>>>>>

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 May 2016 19:39:48 +1000

On 17 May 2016 7:09 PM, "Tal Mizrahi" <[email-masked]> wrote:
> IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, since
these encapsulations do not currently allow the use of IPv6 extension
headers.

Do they specifically prohibit them after the outer fixed IPv6 header?

This is what I'd expect a SR+VXLAN packet to look like coming from a SR
enabled VXLAN tunnel end point.

[IPv6 HDR][SR EH][UDP][VXLAN][tunneled pkt.]

Regards,
Mark.

> >I have some problems to understand where to fit an extension header into
a
> >vxlan encap…

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 23 May 2016 05:50:05 +0000

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.

>From: nvo3 [mailto:[email-masked]] On Behalf Of Tal Mizrahi
>Sent: Tuesday, May 17, 2016 12:09 PM
>To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3-
>[email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]; 6man WG; draft-ietf-6man-segment-
>[email-masked]
>Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-
>routing-header
>
>Stefano,
>
>>Cc: Tal Mizrahi; 6man WG; [email-masked];
>>draft-ietf-6man-segment-routing- [email-masked]
>>use SR. It certainly may be the case in SFC use cases (see Section 2.3
>>in draft- ietf-spring-ipv6-use-cases).
>>>>
>>>
>>> , 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
>>> 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
>>>
>>>>
>>>>
>>>>>>>> 1. What if the encapsulation is VXLAN? L4 would still be
>>>>>>>> involved,
>>right?
>>>>>>>
>>>>>>>
>>>>>>> See below.
>>>>>>>
>>>>>>>
>>>> IETF IPv6 working group mailing list [email-masked] Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>_______________________________________________
>nvo3 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nvo3

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 23 May 2016 09:29:05 +0200

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 <[email-masked]> wrote:

> 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.
>
>
>
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 23 May 2016 07:35:04 +0000

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:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:29 AM
To: Tal Mizrahi
Cc: [email-masked]; 6man WG; [email-masked]; [email-masked]; [email-masked]; [email-masked]; 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 <[email-masked]<mailto:[email-masked]>> wrote:
Dear Authors of VXLAN-GPE / Geneve,

Thanks,
Tal.

>From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tal Mizrahi
>[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 6man WG; draft-ietf-6man-segment-
>[email-masked]<mailto:[email-masked]>
>>From: Stefano Previdi (sprevidi) [mailto:[email-masked]<mailto:[email-masked]>]
>>Cc: Tal Mizrahi; 6man WG; [email-masked]<mailto:[email-masked]>;
>>draft-ietf-6man-segment-routing- [email-masked]<mailto:[email-masked]>
>>> On May 16, 2016, at 7:10 PM, Tom Herbert <[email-masked]<mailto:[email-masked]>>
>wrote:
>>>
>>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi <[email-masked]<mailto:[email-masked]>>
>>wrote:
>>>>> From: Stefano Previdi (sprevidi) [mailto:[email-masked]<mailto:[email-masked]>]
>>>>> [email-masked]<mailto:[email-masked]>;
>>>>> [email-masked]<mailto:[email-masked]>; 6man WG
>>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>
>>>>>> Hi Stefano,
>>>>>>
>>>>>>> From: Stefano Previdi (sprevidi) [mailto:[email-masked]<mailto:[email-masked]>]
>>>>>>> [email-masked]<mailto:[email-masked]>;
>>>>>>> [email-masked]<mailto:[email-masked]>; 6man WG
>>>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi <[email-masked]<mailto:[email-masked]>>
>>wrote:
>>>>>>>>
>>>>>>>> Hi Stefano,
>>>>>>>>
>>>>>>>>> From: Stefano Previdi (sprevidi) [mailto:[email-masked]<mailto:[email-masked]>]
>>>>>>>>> Cc: [email-masked]<mailto:[email-masked]>;
>>>>>>>>> [email-masked]<mailto:[email-masked]>; 6man WG
>>>>>>>>>> On May 15, 2016, at 8:06 PM, [email-masked]<mailto:[email-masked]> wrote:
>>>>>>>>>>
>>>>>>>>>> Tal,
>>>>>>>>>>
>>>> IETF IPv6 working group mailing list [email-masked]<mailto:[email-masked]> Administrative
>[email-masked]<mailto:[email-masked]>
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 23 May 2016 09:46:31 +0200

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 <[email-masked]> wrote:

> would imply
> *From:* nvo3 [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Monday, May 23, 2016 10:29 AM
> *To:* Tal Mizrahi
> *Cc:* [email-masked]; 6man WG; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; Stefano Previdi (sprevidi)
>
> *Subject:* Re: [nvo3] [spring] L4 Checksum and
> draft-ietf-6man-segment-routing-header
>
>
>
> Hi Tal,
>
>
>
> > drafts seem to imply
>
>
>

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 23 May 2016 07:54:15 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:47 AM
To: Tal Mizrahi
Cc: [email-masked]; 6man WG; [email-masked]; [email-masked]; [email-masked]; [email-masked]; 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.

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

      Outer IPv6 Header:

Best regards,
Tal.

From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:29 AM
To: Tal Mizrahi
Cc: [email-masked]<mailto:[email-masked]>; 6man WG; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Stefano Previdi (sprevidi)

Hi Tal,

Thx,
R.

Thanks,
Tal.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 23 May 2016 10:09:54 +0200

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 <[email-masked]> 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:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Monday, May 23, 2016 10:47 AM
>
> *To:* Tal Mizrahi
> Indeed .. I saw the figures, but figures are non normative in any
> draft/rfc unless text below specifically spells it out.
>
>
>

---

From: Jesse Gross <[email-masked]>
Date: Mon, 23 May 2016 20:19:58 +0000

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, "[email-masked]<mailto:[email-masked]> on behalf of Robert Raszuk" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Tal,

> authors could explicitly mention that IPv6 extension

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

That makes sense.

Regards,
Tal.

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

To: Tal Mizrahi

Hi Tal,

Best,
Robert.

      Outer IPv6 Header:

Best regards,
Tal.

Hi Tal,

Thx,
R.

Thanks,
Tal.

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Mon, 23 May 2016 20:55:11 +0000

I agree with Robert and Jesse. - Larry

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

Jesse

Hi Tal,

Best,
R.

That makes sense.

Regards,
Tal.

To: Tal Mizrahi

Hi Tal,

Best,
Robert.

      Outer IPv6 Header:

Best regards,
Tal.

Hi Tal,

Thx,
R.

Thanks,
Tal.

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 31 May 2016 15:54:52 +0000

Hi Stefano,

Going back to our original discussion, I believe we can conclude that the L4 Checksum may be interesting in two possible scenarios:

1.       The SRH is generated by the host. In this case the L4 Checksum is computed by the host based on the IP address of the last hop.

2.       The SRH is generated by the ingress node of the SR domain using an IP tunnel. Specifically, if the tunnel encapsulation includes an L4 header (e.g., VXLAN, VXLAN-GPE, Geneve, GUE), then (again) the ingress node computes the L4 Checksum based on the IP address of the last hop.

In both cases intermediate routers in the SR domain do not need to update the Checksum, even though they update the destination IP address.

It would be great if some text would be added to the draft to clarify these observations.

Cheers,
Tal.

From: Larry Kreeger (kreeger) [mailto:[email-masked]]
Sent: Monday, May 23, 2016 11:55 PM
To: Tal Mizrahi
Cc: [email-masked]; [email-masked]; [email-masked]; 6man WG; [email-masked]; [email-masked]; Stefano Previdi (sprevidi)
Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header

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

Hi Tal,

Best,
R.

That makes sense.

Regards,
Tal.

To: Tal Mizrahi

Hi Tal,

Best,
Robert.

      Outer IPv6 Header:

Best regards,
Tal.

Hi Tal,

Thx,
R.

Thanks,
Tal.

>>>>> it's all about IP, not layer-2.
>>>>>
>>>>> s.
>>>>
>>I have some problems to understand where to fit an extension header
>>into a vxlan encap...
>>
>>
>>of the routing extension header defined in rfc2460. That's the context.
>>
>>
>>s.
>>
>>
>>
>>
>>>
>>> Tom
>>>
>>>>
>>>>
>>>>> it's all about IP, not layer-2.
>>>>>
>>>>> s.
>>>>>
>>>>>
>>>>>>>>> encapsulation so clearly there's no L4 involved here.
>>>>>>>>>
>>>>>>>>> s.
>>>>>>>>
>>>>>>>> Two questions:
>>>>>>> Here, theres' nothing new  compared to rfc2460.
>>>>>>>
>>>>>>>>>>> According to draft-ietf-6man-segment-routing-header, an 'SR
>>>>>>>>>>> Segment
>>>>>>>>> Endpoint Node' updates the Destination IP address.
>>>>>>>>> encapsulation so clearly there's no L4 involved here.
>>>>>>>>>
>>>>>>>>> s.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Ole
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 31 May 2016 16:02:38 +0000

> On May 31, 2016, at 5:54 PM, Tal Mizrahi <[email-masked]> wrote:
> 
> Hi Stefano,
> 

it can be simplified by stating that any SRH that is inserted in transit MUST be removed prior to deliver the packet to the final destination.

All other cases implies that the source is inserting the SRH, in which case the checksum is consistent.

s.

>>>>>>>>>>>> Speaking from a chip vendor's perspective this may be a problem