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
