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 protected]] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:29 AM
To: Tal Mizrahi
Cc: [email protected]; 6man WG; [email protected];
[email protected]; [email protected];
[email protected]; 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 protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>] On
>Behalf Of Tal Mizrahi
>Sent: Tuesday, May 17, 2016 12:09 PM
>To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3-
>[email protected]<mailto:[email protected]>;
>[email protected]<mailto:[email protected]>
>Cc: [email protected]<mailto:[email protected]>;
>[email protected]<mailto:[email protected]>; 6man WG; draft-ietf-6man-segment-
>[email protected]<mailto:[email protected]>
>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:[email protected]<mailto:[email protected]>]
>>Sent: Tuesday, May 17, 2016 10:41 AM
>>To: Tom Herbert
>>Cc: Tal Mizrahi; 6man WG; [email protected]<mailto:[email protected]>;
>>draft-ietf-6man-segment-routing-
>>[email protected]<mailto:[email protected]>
>>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-
>>header
>>
>>
>>> On May 16, 2016, at 7:10 PM, Tom Herbert
>>> <[email protected]<mailto:[email protected]>>
>wrote:
>>>
>>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi
>>> <[email protected]<mailto:[email protected]>>
>>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:[email protected]<mailto:[email protected]>]
>>>>> Sent: Monday, May 16, 2016 2:24 PM
>>>>> To: Tal Mizrahi
>>>>> Cc: Ole Trøan;
>>>>> [email protected]<mailto:[email protected]>;
>>>>> [email protected]<mailto:[email protected]>; 6man WG
>>>>> Subject: Re: [spring] L4 Checksum and
>>>>> draft-ietf-6man-segment-routing- header
>>>>>
>>>>>
>>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi
>>>>>> <[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
>>>>>>> Sent: Monday, May 16, 2016 2:13 PM
>>>>>>> To: Tal Mizrahi
>>>>>>> Cc: Ole Trøan;
>>>>>>> [email protected]<mailto:[email protected]>;
>>>>>>> [email protected]<mailto:[email protected]>; 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
>>>>>>> <[email protected]<mailto:[email protected]>>
>>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:[email protected]<mailto:[email protected]>]
>>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM
>>>>>>>>> To: Ole Trøan; Tal Mizrahi
>>>>>>>>> Cc:
>>>>>>>>> [email protected]<mailto:[email protected]>;
>>>>>>>>> [email protected]<mailto:[email protected]>; 6man WG
>>>>>>>>> Subject: Re: [spring] L4 Checksum and
>>>>>>>>> draft-ietf-6man-segment-routing- header
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On May 15, 2016, at 8:06 PM,
>>>>>>>>>> [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]>
>>>> Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>
>_______________________________________________
>nvo3 mailing list
>[email protected]<mailto:[email protected]>
>https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
spring mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
