Re: [Apn] Comments on draft-li-apn-ipv6-encap-01

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Wed, 30 March 2022 00:30 UTC

Return-Path: <pengshuping@huawei.com>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF033A183E for <apn@ietfa.amsl.com>; Tue, 29 Mar 2022 17:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.337
X-Spam-Level:
X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 fROmQibE5DMh for <apn@ietfa.amsl.com>; Tue, 29 Mar 2022 17:30:00 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3BAB3A183D for <apn@ietf.org>; Tue, 29 Mar 2022 17:29:59 -0700 (PDT)
Received: from fraeml706-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KSnMm1rnCz67x2x; Wed, 30 Mar 2022 08:28:04 +0800 (CST)
Received: from canpemm100007.china.huawei.com (7.192.105.181) by fraeml706-chm.china.huawei.com (10.206.15.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.24; Wed, 30 Mar 2022 02:29:55 +0200
Received: from canpemm500008.china.huawei.com (7.192.105.151) by canpemm100007.china.huawei.com (7.192.105.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 30 Mar 2022 08:29:54 +0800
Received: from canpemm500008.china.huawei.com ([7.192.105.151]) by canpemm500008.china.huawei.com ([7.192.105.151]) with mapi id 15.01.2308.021; Wed, 30 Mar 2022 08:29:53 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: Donald Eastlake <d3e3e3@gmail.com>, apn <apn@ietf.org>
Thread-Topic: [Apn] Comments on draft-li-apn-ipv6-encap-01
Thread-Index: AQHYQ6aQ8Advs+TlRUS93FxVkLjVnqzXEz/k
Date: Wed, 30 Mar 2022 00:29:53 +0000
Message-ID: AFAE1E8C-5E80-44FA-8CFF-0E98C4E7424C
References: <CAF4+nEGh6PB0+npSs59+LNv0qwAM+uSEbOCHXhys50gDbdVb=w@mail.gmail.com>
In-Reply-To: <CAF4+nEGh6PB0+npSs59+LNv0qwAM+uSEbOCHXhys50gDbdVb=w@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_AFAE1E8C5E8044FA8CFF0E98C4E7424C_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/zs3ziIm3M6vhS70H3M287HxoaAU>
Subject: Re: [Apn] Comments on draft-li-apn-ipv6-encap-01
X-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2022 00:30:05 -0000

Hi Donald,

Many thanks for your detailed review and suggestions! We will update the draft accordingly.

Thank you!

Best regards,
Shuping




________________________________

彭书萍 Peng Shuping
Mobile: +86-18210364128(优先)
Email: pengshuping@huawei.com

发件人:Donald Eastlake <d3e3e3@gmail.com>
收件人:apn <apn@ietf.org>
时 间:2022-03-30 03:52:48
主 题:[Apn] Comments on draft-li-apn-ipv6-encap-01

I have reviewed this draft and have some comments that I believe would improve it, mostly by clarifying it:

The Requirement Language section should be updated to the current required wording referencing RFC 8174 as well as RFC 2119.

Section 2: Add SRH to the list of acronyms with a reference to RFC 8754.

Section 3:

In the first sentence "one option" -> "one IPv6 Header option [RFC8200]"

In Figure 1, the "Opt Type" field should probably be something like "Opt Type=TBD2"

In the list of fields after Figure 1, it currently lists "Option Data" but that should be changed to "APN Header" which is what it says in the figure.

Section 4.1: "Hop-by-Hop Options" -> "IPv6 Hop-by-Hop Options"

Section 4.2: Suggest inserting "but would not normally be seen by other nodes" in the last sentence between "destination node" and "along".

Section 5:

Similar to the change in Figure 1, in Figure 2 the "Type" field should say something like "Type=TBD1".

In the list of fields after Figure 2, for Type is should just say "TBD1" instead of "to be assigned by IANA", for RESERVED add "and ignored on receipt", and for APN Header, it should reference [I.D.li-apn-header].

Section 6, IANA Considerations: In my opinion, this section needs a more-or-less complete replacement. Also, for the IPv6 Header Option, it needs to specify the bits that indicate whether the option can change in flight (I'm guessing it can't) and what to do if the option is not known (my guess is ignore it). So I suggest replacing this section with something like the following:


6. IANA Considerations


   IANA is requested to assign two code points as below.



6.1 IPv6 Header Option



   IANA is requested to assign an IPv6 Header Option as follows:



   Hex      Binary Value

   Value    act chg rest    Description                   Reference

   -----    --- --- -----  ----------------------------  ---------------

    TBD1     00   0 xxxxx  Application-aware Networking  [this document]



   RFC Editor / IANA Note: To be removed when RFC is published. xxxxx is the binary for the bottom 5 bits of RBD1.



6.2 SRH TLV Type



   IANA is requested to assign an SRH TLV Type as follows:



   Value    Description                    Reference

   -----   ----------------------------   -----------------

    TBD2   Application-aware Networking    [this document]

References: I think that RFCs 8174 and 8200 should be added to the normative references.

There were also some additional minor editorial suggestions that I sent directly to the authors.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>