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