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 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
