On 17 May 2016 7:09 PM, "Tal Mizrahi" <[email protected]> wrote: > > 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. >
Do they specifically prohibit them after the outer fixed IPv6 header? This is what I'd expect a SR+VXLAN packet to look like coming from a SR enabled VXLAN tunnel end point. [IPv6 HDR][SR EH][UDP][VXLAN][tunneled pkt.] Regards, Mark. > 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 > >>> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > 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
