>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).
>-----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 >>>>>> >>>> >> _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
