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