> 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 >> -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
