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, but I don't think it is explicit as to exact encapsulation format (I suppose simple ip6ip6 is implied). But, it seems like any of several encapsulation techniques could work (VXLAN, 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? 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 > -------------------------------------------------------------------- _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
