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 protected]> 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 protected] [mailto:[email protected]] *On Behalf Of *Robert > Raszuk > *Sent:* Monday, May 23, 2016 10:47 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, > > > > 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 protected]> wrote: > > 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]> 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]] 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 > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > > > > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
