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 <ta...@marvell.com> 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:nvo3-boun...@ietf.org] On Behalf Of Tal Mizrahi > >Sent: Tuesday, May 17, 2016 12:09 PM > >To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3- > >gen...@tools.ietf.org; draft-ietf-nvo3-vxlan-...@tools.ietf.org > >Cc: spring@ietf.org; n...@ietf.org; 6man WG; draft-ietf-6man-segment- > >routing-hea...@tools.ietf.org > >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:sprev...@cisco.com] > >>Sent: Tuesday, May 17, 2016 10:41 AM > >>To: Tom Herbert > >>Cc: Tal Mizrahi; 6man WG; spring@ietf.org; > >>draft-ietf-6man-segment-routing- hea...@tools.ietf.org > >>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing- > >>header > >> > >> > >>> On May 16, 2016, at 7:10 PM, Tom Herbert <t...@herbertland.com> > >wrote: > >>> > >>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi <ta...@marvell.com> > >>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:sprev...@cisco.com] > >>>>> Sent: Monday, May 16, 2016 2:24 PM > >>>>> To: Tal Mizrahi > >>>>> Cc: Ole Trøan; > >>>>> draft-ietf-6man-segment-routing-hea...@tools.ietf.org; > >>>>> spring@ietf.org; 6man WG > >>>>> Subject: Re: [spring] L4 Checksum and > >>>>> draft-ietf-6man-segment-routing- header > >>>>> > >>>>> > >>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi <ta...@marvell.com> 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:sprev...@cisco.com] > >>>>>>> Sent: Monday, May 16, 2016 2:13 PM > >>>>>>> To: Tal Mizrahi > >>>>>>> Cc: Ole Trøan; > >>>>>>> draft-ietf-6man-segment-routing-hea...@tools.ietf.org; > >>>>>>> spring@ietf.org; 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 <ta...@marvell.com> > >>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:sprev...@cisco.com] > >>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM > >>>>>>>>> To: Ole Trøan; Tal Mizrahi > >>>>>>>>> Cc: draft-ietf-6man-segment-routing-hea...@tools.ietf.org; > >>>>>>>>> spring@ietf.org; 6man WG > >>>>>>>>> Subject: Re: [spring] L4 Checksum and > >>>>>>>>> draft-ietf-6man-segment-routing- header > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> On May 15, 2016, at 8:06 PM, otr...@employees.org 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 i...@ietf.org Administrative > >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> -------------------------------------------------------------------- > > > >_______________________________________________ > >nvo3 mailing list > >n...@ietf.org > >https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
