Re: [spring] SRv6 Network Programming: ENH = 59

Xiejingrong <xiejingrong@huawei.com> Mon, 06 May 2019 01:15 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B639120041; Sun, 5 May 2019 18:15:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 uNPN7kqtFJkO; Sun, 5 May 2019 18:15:24 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A370B120043; Sun, 5 May 2019 18:15:23 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2F58359783EAA22C656E; Mon, 6 May 2019 02:15:21 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 6 May 2019 02:15:20 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0415.000; Mon, 6 May 2019 09:15:06 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: Tom Herbert <tom@herbertland.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
CC: SPRING WG <spring@ietf.org>, 6man <ipv6@ietf.org>
Thread-Topic: SRv6 Network Programming: ENH = 59
Thread-Index: AdUDo1cr1ntuHPleQoe8AvXX2JxkXv//hEOA//95diA=
Date: Mon, 06 May 2019 01:15:05 +0000
Message-ID: <16253F7987E4F346823E305D08F9115AAB88504C@nkgeml514-mbx.china.huawei.com>
References: <BYAPR05MB4245988C3A47C3665BD91172AE300@BYAPR05MB4245.namprd05.prod.outlook.com> <CALx6S358r54Z7U_GM88PnTDmd503BAjE6-ff9CDpjyAY4Cq_sg@mail.gmail.com>
In-Reply-To: <CALx6S358r54Z7U_GM88PnTDmd503BAjE6-ff9CDpjyAY4Cq_sg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.217.214]
Content-Type: multipart/alternative; boundary="_000_16253F7987E4F346823E305D08F9115AAB88504Cnkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/kGhn8rZhE6NAIjpzTQwdrYykV3U>
Subject: Re: [spring] SRv6 Network Programming: ENH = 59
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2019 01:15:26 -0000

Hi Tom,

Number 97 is a choice but it has 2 bytes wasting.

Jingrong

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert
Sent: Monday, May 06, 2019 9:11 AM
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: SPRING WG <spring@ietf.org>; 6man <ipv6@ietf.org>
Subject: Re: SRv6 Network Programming: ENH = 59


On Sun, May 5, 2019, 5:47 PM Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:
Folks,

According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00, when processing the End.DX2 SID, the Next Header must be equal to 59. Otherwise, the packet will be dropped.

In the words of the draft, "We conveniently reuse the next-header value 59 allocated to IPv6 No Next Header [RFC8200].  When the SID corresponds to function End.DX2 and the Next-Header value is 59, we know that an Ethernet frame is in the payload without any further header."

According to Section 4.7 RFC 8200, " The value 59 in the Next Header field of an IPv6 header or any  extension header indicates that there is nothing following that header.  If the Payload Length field of the IPv6 header indicates the presence of octets past the end of a header whose Next Header field contains 59, those octets must be ignored and passed on unchanged if the packet is forwarded."

Does the WG think that it is a good idea to reuse the Next Header value 59? Or would it be better to allocate a new Next Header value that represents Ethernet?

Tom,

There's already ETHERIP number (97). Why not use that?

Tom


                                                          Ron


Juniper Internal

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------