RE: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header
Tal Mizrahi <talmi@marvell.com> Mon, 23 May 2016 07:35 UTC
Return-Path: <talmi@marvell.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF9612D567; Mon, 23 May 2016 00:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xO9Pt7FwYQnR; Mon, 23 May 2016 00:35:10 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A9812B032; Mon, 23 May 2016 00:35:10 -0700 (PDT)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u4N7VJ1v017327; Mon, 23 May 2016 00:35:09 -0700
Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 232q6e4vap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 23 May 2016 00:35:08 -0700
Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 May 2016 10:35:05 +0300
Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Mon, 23 May 2016 10:35:05 +0300
From: Tal Mizrahi <talmi@marvell.com>
To: Robert Raszuk <robert@raszuk.net>
Subject: RE: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header
Thread-Topic: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header
Thread-Index: AQHRtMThJCvw5mf6XUe954CmH3IV2Z/GIJVA
Date: Mon, 23 May 2016 07:35:04 +0000
Message-ID: <bb99730deb8348bcac4f5c433e88d435@IL-EXCH02.marvell.com>
References: <eaf5cad817624c7a8758758aa058399b@IL-EXCH02.marvell.com> <AD825FC8-E5AB-437D-992B-F5900B67EFA7@employees.org> <ECB16B90-392C-4C98-B3EA-86050AE2BEBA@cisco.com> <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <A5EFDE4C-BE25-4F5C-B176-E63740E94F4B@cisco.com> <ed76a19f5995465e8f4eddcba5d0c95c@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> <CALx6S35iChUWbF_Qp6Sf2s5ipPDqkNfVB1k0i=45Nq5q4OnS_w@mail.gmail.com> <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> <569a4067fd1f45dd85d60e983be69b90@IL-EXCH02.marvell.com> <CA+b+ER=zQbceetmYE-ehVczCVTcx0tawEZb1bdRB9ZktdfW7ZA@mail.gmail.com>
In-Reply-To: <CA+b+ER=zQbceetmYE-ehVczCVTcx0tawEZb1bdRB9ZktdfW7ZA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.4.102.210]
Content-Type: multipart/alternative; boundary="_000_bb99730deb8348bcac4f5c433e88d435ILEXCH02marvellcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-23_02:, , signatures=0
X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605230091
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/jYPxxl-kNfRyrRrJ_NmMvs2lcMs>
Cc: "spring@ietf.org" <spring@ietf.org>, 6man WG <ipv6@ietf.org>, "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" <draft-ietf-nvo3-vxlan-gpe@tools.ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>, "draft-ietf-6man-segment-routing-header@tools.ietf.org" <draft-ietf-6man-segment-routing-header@tools.ietf.org>, "draft-ietf-nvo3-geneve@tools.ietf.org" <draft-ietf-nvo3-geneve@tools.ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 May 2016 07:35:17 -0000
Hi Robert, > Where say in draft draft-quinn-vxlan-gpe do you see such statement that would imply > that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to any other type > of extension header further followed by UDP ? The following text is from Figure 4 in draft-ietf-nvo3-vxlan-gpe: Outer IPv6 Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | NxtHdr=17(UDP)| Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | There is a similar figure in draft-ietf-nvo3-geneve. Best regards, Tal. From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Monday, May 23, 2016 10:29 AM To: Tal Mizrahi Cc: spring@ietf.org; 6man WG; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org; nvo3@ietf.org; draft-ietf-6man-segment-routing-header@tools.ietf.org; draft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi) Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Hi Tal, > drafts seem to imply Where say in draft draft-quinn-vxlan-gpe do you see such statement that would imply that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to any other type of extension header further followed by UDP ? Thx, R. On Mon, May 23, 2016 at 7:50 AM, Tal Mizrahi <talmi@marvell.com<mailto:talmi@marvell.com>> wrote: Dear Authors of VXLAN-GPE / Geneve, I am reiterating on this question, as I haven't seen a response yet: Have you considered the use of Segment Routing with VXLAN-GPE / Geneve? The current VXLAN-GPE / Geneve drafts seem to imply that IPv6 extension headers are currently not supported. Thanks, Tal. >-----Original Message----- >From: nvo3 [mailto:nvo3-bounces@ietf.org<mailto:nvo3-bounces@ietf.org>] On Behalf Of Tal Mizrahi >Sent: Tuesday, May 17, 2016 12:09 PM >To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3- >geneve@tools.ietf.org<mailto:geneve@tools.ietf.org>; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org<mailto:draft-ietf-nvo3-vxlan-gpe@tools.ietf.org> >Cc: spring@ietf.org<mailto:spring@ietf.org>; nvo3@ietf.org<mailto:nvo3@ietf.org>; 6man WG; draft-ietf-6man-segment- >routing-header@tools.ietf.org<mailto:routing-header@tools.ietf.org> >Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment- >routing-header > >Stefano, > >If I understand your point correctly: >IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, since >these encapsulations do not currently allow the use of IPv6 extension >headers. > >I wonder if the authors of VXLAN-GPE and Geneve have considered the use of >segment routing. > >Thanks, >Tal. > > > >>-----Original Message----- >>From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com<mailto:sprevidi@cisco.com>] >>Sent: Tuesday, May 17, 2016 10:41 AM >>To: Tom Herbert >>Cc: Tal Mizrahi; 6man WG; spring@ietf.org<mailto:spring@ietf.org>; >>draft-ietf-6man-segment-routing- header@tools.ietf.org<mailto:header@tools.ietf.org> >>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing- >>header >> >> >>> On May 16, 2016, at 7:10 PM, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> >wrote: >>> >>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi <talmi@marvell.com<mailto:talmi@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:sprevidi@cisco.com<mailto:sprevidi@cisco.com>] >>>>> Sent: Monday, May 16, 2016 2:24 PM >>>>> To: Tal Mizrahi >>>>> Cc: Ole Trøan; >>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org<mailto:draft-ietf-6man-segment-routing-header@tools.ietf.org>; >>>>> spring@ietf.org<mailto: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 <talmi@marvell.com<mailto:talmi@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:sprevidi@cisco.com<mailto:sprevidi@cisco.com>] >>>>>>> Sent: Monday, May 16, 2016 2:13 PM >>>>>>> To: Tal Mizrahi >>>>>>> Cc: Ole Trøan; >>>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org<mailto:draft-ietf-6man-segment-routing-header@tools.ietf.org>; >>>>>>> spring@ietf.org<mailto: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 <talmi@marvell.com<mailto:talmi@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:sprevidi@cisco.com<mailto:sprevidi@cisco.com>] >>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM >>>>>>>>> To: Ole Trøan; Tal Mizrahi >>>>>>>>> Cc: draft-ietf-6man-segment-routing-header@tools.ietf.org<mailto:draft-ietf-6man-segment-routing-header@tools.ietf.org>; >>>>>>>>> spring@ietf.org<mailto: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, otroan@employees.org<mailto:otroan@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 ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org<mailto:nvo3@ietf.org> >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
- L4 Checksum and draft-ietf-6man-segment-routing-h… Tal Mizrahi
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… otroan
- RE: [spring] L4 Checksum and draft-ietf-6man-segm… Tal Mizrahi
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Stefano Previdi (sprevidi)
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Stefano Previdi (sprevidi)
- RE: [spring] L4 Checksum and draft-ietf-6man-segm… Tal Mizrahi
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Stefano Previdi (sprevidi)
- RE: [spring] L4 Checksum and draft-ietf-6man-segm… Tal Mizrahi
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Stefano Previdi (sprevidi)
- RE: [spring] L4 Checksum and draft-ietf-6man-segm… Tal Mizrahi
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Tom Herbert
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Stefano Previdi (sprevidi)
- RE: [spring] L4 Checksum and draft-ietf-6man-segm… Tal Mizrahi
- RE: [spring] L4 Checksum and draft-ietf-6man-segm… Mark Smith
- Re: L4 Checksum and draft-ietf-6man-segment-routi… Alexandre Petrescu
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Alexandre Petrescu
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Alexandre Petrescu
- Re: L4 Checksum and draft-ietf-6man-segment-routi… Mark Smith
- Re: L4 Checksum and draft-ietf-6man-segment-routi… Tom Herbert
- RE: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Tal Mizrahi
- Re: [spring] [nvo3] L4 Checksum and draft-ietf-6m… Robert Raszuk
- RE: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Tal Mizrahi
- Re: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Robert Raszuk
- RE: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Tal Mizrahi
- Re: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Robert Raszuk
- Re: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Jesse Gross
- Re: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Larry Kreeger (kreeger)
- RE: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Tal Mizrahi
- Re: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Stefano Previdi (sprevidi)