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

Take the IOAM as an example, the action needs to be performed hop by hop along the path. However, when some routers along the path enable the processing of the HBH but others just ignore it. Then the IOAM service fails. Therefore, the enforcement of the processing of the HBH according to the service requirements would be required in the procedure wise.

Shuping

发件人: Mark Smith [mailto:markzzzsmith@gmail.com]
发送时间: 2019年7月10日 21:10
收件人: Pengshuping (Peng Shuping) <pengshuping@huawei.com>
抄送: C. M. Heard <heard@pobox.com>; 6man WG <ipv6@ietf.org>
主题: Re: Comments on draft-li-6man-enhanced-extension-header Sec 2.1

On Wed., 10 Jul. 2019, 22:53 Pengshuping (Peng Shuping), <pengshuping@huawei.com<mailto:pengshuping@huawei.com>> wrote:
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,

This was an observation on what some routers were doing with the HbH header, not something describing preferred handling. Note that the previous version of RFC 8200, RFC 2460, mandated HbH processing at all forwarding hops.

I agree with Mike, defining a copy of the existing HbH EH with a different NH value isn't going to overcome router implementation limitations.

If people are able to build routers that can handle the HbH header properly without sending it to the slow path, then there is no problem, and the existing HbH EH can be used as it is.

Regards,
Mark.

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<mailto:ipv6-bounces@ietf.org>] 代表 C. M. Heard
发送时间: 2019年7月10日 12:11
收件人: 6man <ipv6@ietf.org<mailto: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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------