IETF Logo Mail Archive

答复: Comments on draft-li-6man-enhanced-extension-header Sec 2.1

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Wed, 10 July 2019 12:52 UTC

Return-Path: <pengshuping@huawei.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 C6390120134 for <ipv6@ietfa.amsl.com>; Wed, 10 Jul 2019 05:52:44 -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=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 xy-yxkbBYFIv for <ipv6@ietfa.amsl.com>; Wed, 10 Jul 2019 05:52:41 -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 7B26012012C for <ipv6@ietf.org>; Wed, 10 Jul 2019 05:52:41 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4783D483B5A4F369357B for <ipv6@ietf.org>; Wed, 10 Jul 2019 13:45:09 +0100 (IST)
Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 10 Jul 2019 13:44:48 +0100
Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.81]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0439.000; Wed, 10 Jul 2019 20:44:17 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: "C. M. Heard" <heard@pobox.com>, 6man <ipv6@ietf.org>
Subject: 答复: Comments on draft-li-6man-enhanced-extension-header Sec 2.1
Thread-Topic: Comments on draft-li-6man-enhanced-extension-header Sec 2.1
Thread-Index: AQHVNtWJ9VJynMEzNkOxlpH2YeiDrabDxMsw
Date: Wed, 10 Jul 2019 12:44:16 +0000
Message-ID: <4278D47A901B3041A737953BAA078ADE148446F8@dggeml512-mbx.china.huawei.com>
References: <CACL_3VGP4-kmyJGo1Gxea7HhcKY3P3EGHwgmcYxCGLnjPh-YCg@mail.gmail.com>
In-Reply-To: <CACL_3VGP4-kmyJGo1Gxea7HhcKY3P3EGHwgmcYxCGLnjPh-YCg@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.45.171.18]
Content-Type: multipart/alternative; boundary="_000_4278D47A901B3041A737953BAA078ADE148446F8dggeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GPjuICIJ-aPXyGKyQxro08qrPOA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 10 Jul 2019 12:52:45 -0000

Hi Mike,

We are aware of the note in RFC8200. However, as we stated in the draft, according to the current specifications, nodes may be configured to ignore the HBH Options Header, and the packets with it may be dropped or assigned to a slow processing path, which will greatly reduce the forwarding performance when supporting the new services such as IOAM.

We aim to define a new HBH Options header which still has the hop-by-hop behavior but is processed at wire speed instead of being assigned to the slow path.

This new HBH Options header is identified by a different next header value. It shares the same structure of the HBH in RFC8200 for the purpose of sharing the existing options already defined and also keeping the compatibility with the existing IPv6 deployments.

Shuping


发件人: ipv6 [mailto:ipv6-bounces@ietf.org] 代表 C. M. Heard
发送时间: 2019年7月10日 12:11
收件人: 6man <ipv6@ietf.org>
主题: Comments on draft-li-6man-enhanced-extension-header Sec 2.1

I see in Section 2.1 of this draft the definition of an enhanced Hop-by-Hop Options Header.

Since its format and function are identical with that of the existing Hop-by-Hop Options Header, I fail to see what it could possibly accomplish.

Moreover, it is in direct contradiction with the following directive in Section 2.8 of RFC 8200:


   Note: New extension headers that require hop-by-hop behavior must not

   be defined because, as specified in Section 4<https://tools.ietf.org/html/rfc8200#section-4> of this document, the

   only extension header that has hop-by-hop behavior is the Hop-by-Hop

   Options header.

Mike Heard

v2.23.0 | Report a Bug | By Email