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> 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] *代表 *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
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>