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

From: "C. M. Heard" <[email-masked]>
Date: Tue, 9 Jul 2019 21:10:34 -0700

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

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Wed, 10 Jul 2019 12:44:16 +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:[email-masked]] 代表 C. M. Heard
发送时间: 2019年7月10日 12:11
收件人: 6man <[email-masked]>
主题: 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:

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

   Options header.

Mike Heard

---

From: Mark Smith <[email-masked]>
Date: Wed, 10 Jul 2019 23:09:30 +1000

On Wed., 10 Jul. 2019, 22:53 Pengshuping (Peng Shuping), <
[email-masked]> 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:[email-masked]] *代表 *C. M. Heard
> *发送时间:* 2019年7月10日 12:11
> *收件人:* 6man <[email-masked]>
> *主题:* Comments on draft-li-6man-enhanced-extension-header Sec 2.1
>
>
>
>    be defined because, as specified in Section 4 <https://tools.ietf.org/html/rfc8200#section-4> of this document, the
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Wed, 10 Jul 2019 13:37:43 +0000

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:[email-masked]]
发送时间: 2019年7月10日 21:10
收件人: Pengshuping (Peng Shuping) <[email-masked]>
抄送: C. M. Heard <[email-masked]>; 6man WG <[email-masked]>
主题: Re: Comments on draft-li-6man-enhanced-extension-header Sec 2.1

On Wed., 10 Jul. 2019, 22:53 Pengshuping (Peng Shuping), <[email-masked]<mailto:[email-masked]>> 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.

Shuping

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

   Options header.

Mike Heard
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 10 Jul 2019 08:13:33 -0700

On Wed, Jul 10, 2019 at 6:38 AM Pengshuping (Peng Shuping) wrote:
> 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.

So what you want is a Hop-by-Hop Options header that all nodes along
the path must process. As Mark pointed out, we've been down that road
before: both RFC 2460 Section 4.3
<https://tools.ietf.org/html/rfc2460#section-4.3> and RFC 1883 Section 4.3
<https://tools.ietf.org/html/rfc1883#section-4.3> (its
predecessor) contained the following text.

   The Hop-by-Hop Options header is used to carry optional information
   that must be examined by every node along a packet's delivery path.

In the 2+ decades following the publication of RFC 1883 that idea never
caught on, That's why RFC 8200 Section 4 added the note

   NOTE: While [RFC2460 <https://tools.ietf.org/html/rfc2460>]
required that all nodes must examine and
   process the Hop-by-Hop Options header, it is now expected that nodes
   along a packet's delivery path only examine and process the
   Hop-by-Hop Options header if explicitly configured to do so.

and why RFC 8200 Section 4.3
<https://tools.ietf.org/html/rfc8200#section-4.3> now says

   The Hop-by-Hop Options header is used to carry optional information
   that may be examined and processed by every node along a packet's
   delivery path.

Based on the decades of  experience, it's fair to say that the true
hop-by-hop behavior as needed for IOAM to work cannot be expected in
the general Internet. Putting the Hop-by-Hop Options header in a
new Next Header type will not magically change that. It will, however,
cause backward compatibility problems in end systems, because they
will see an unknown Next Header type and drop the packet (see
RFC 8200 Section 4 <https://tools.ietf.org/html/rfc8200#section-4>):

   If, as a result of processing a header, the destination node is
   required to proceed to the next header but the Next Header value in
   the current header is unrecognized by the node, it should discard the
   packet and send an ICMP Parameter Problem message to the source of
   the packet, with an ICMP Code value of 1 ("unrecognized Next Header
   type encountered") and the ICMP Pointer field containing the offset
   of the unrecognized value within the original packet.  The same
   action should be taken if a node encounters a Next Header value of
   zero in any header other than an IPv6 header.

The best that can be expected is that true hop-by-hop behavior, as
required for IOAM to work as desired, can be made to work in a
controlled environment (aka limited domain) wherein every router is
able to process the Hop-by-Hop Options header at wire speed and has
been configured to do so. A new Next Header type is not needed to
accomplish that.

Mike Heard

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 11 Jul 2019 06:43:28 +0000

Hi Mike,

On the following words, I am still not clear. If the node is able or configured to examine and process the hbh header, we still do not know whether it can be processed in fast path.

   NOTE: While [RFC2460<https://tools.ietf.org/html/rfc2460>] required that all nodes must examine and

I find one relevant draft, but it’s expired.
https://www.ietf.org/archive/id/draft-ietf-6man-hbh-header-handling-03.txt

Tianran

From: ipv6 [mailto:[email-masked]] On Behalf Of C. M. Heard
Sent: Wednesday, July 10, 2019 11:14 PM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: Comments on draft-li-6man-enhanced-extension-header Sec 2.1

So what you want is a Hop-by-Hop Options header that all nodes along
the path must process. As Mark pointed out, we've been down that road
before: both RFC 2460 Section 4.3<https://tools.ietf.org/html/rfc2460#section-4.3> and RFC 1883 Section 4.3<https://tools.ietf.org/html/rfc1883#section-4.3> (its
predecessor) contained the following text.

   NOTE: While [RFC2460<https://tools.ietf.org/html/rfc2460>] required that all nodes must examine and

and why RFC 8200 Section 4.3<https://tools.ietf.org/html/rfc8200#section-4.3> now says

   delivery path.

RFC 8200 Section 4<https://tools.ietf.org/html/rfc8200#section-4>):

Mike Heard

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 12 Jul 2019 02:19:22 +0000

From: C. M. Heard [mailto:[email-masked]]
Sent: Wednesday, July 10, 2019 11:14 PM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: Mark Smith <[email-masked]>; 6man WG <[email-masked]>; Lizhenbin <[email-masked]>
Subject: Re: Comments on draft-li-6man-enhanced-extension-header Sec 2.1

   delivery path.

[Shuping] The configuration you propose here will be effective to all the options contained in the HBH Options header. However, there are multiple different options in the HBH Options header, which usually require different processing procedures, e.g. being assigned to the slow path or processed at wire speed. The way to differentiate the treatments to those options is currently missing.

We could do engineering at each option to indicate every router how to treat it. However, that will not be very efficient since each option type needs to be gone through and checked against the preset configuration.

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 11 Jul 2019 20:40:27 -0700

On Thu, Jul 11, 2019 at 7:19 PM Pengshuping (Peng Shuping) <
[email-masked]> wrote:

> We could do engineering at each option to indicate every router how to
> treat it. However, that will not be very efficient since each option type
> needs to be gone through and checked against the preset configuration.
>

The new header that you propose uses the same options, so how would it be
different?

Mike Heard

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Mon, 15 Jul 2019 02:04:24 +0000

The draft says that “The Options can be shared with the original Hop-by-Hop Options Header.” Not the same.

Basically, the options are categorized based on their requirements of different processing by being placed into different HBH option headers. In the new HBH header if present, all the carried options will be processed at wire speed instead of being dispatched to CPU.

Shuping

Sent: Friday, July 12, 2019 11:40 AM

On Thu, Jul 11, 2019 at 7:19 PM Pengshuping (Peng Shuping) <[email-masked]<mailto:[email-masked]>> wrote:
We could do engineering at each option to indicate every router how to treat it. However, that will not be very efficient since each option type needs to be gone through and checked against the preset configuration.

The new header that you propose uses the same options, so how would it be different?

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 14 Jul 2019 19:53:41 -0700

We've been down that road before. That's how the existing HbH Options
Header was supposed to work when it was defined in RFC 2460 (and RFC 1883
before that). Mandating the behavior in those specs did not make it happen
(and that's why RFC 8200 relaxed the requirement). Why do you think that
mandating the behavior in a new spec (with a new Next Header type) will
result in a different outcome?

Additionally, it is not true that a new Next Header type with Hop-by-Hop
behavior is in any way backward compatible. RFCs 1883, 2360, and 8200
specifically disallow that, and existing IPv6 nodes have the assumption
that the only Next Header type with HbH behavior is 0x00 "baked in."

Mike Heard

On Sun, Jul 14, 2019 at 7:04 PM Pengshuping (Peng Shuping) <
[email-masked]> wrote:

> *From:* C. M. Heard [mailto:[email-masked]]
> *Sent:* Friday, July 12, 2019 11:40 AM
> *To:* Pengshuping (Peng Shuping) <[email-masked]>
> *Cc:* Mark Smith <[email-masked]>; 6man WG <[email-masked]>;
> Lizhenbin <[email-masked]>
> *Subject:* Re: Comments on draft-li-6man-enhanced-extension-header Sec 2.1
>
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Jul 2019 16:00:02 +1200

Hi,

Both segment routing and OAM are mentioned as use cases in
https://tools.ietf.org/html/draft-carpenter-limited-domains-09.
These are typically features that will be on the fast path by
configuration in a particular domain, and will not work properly
outside such a domain.

Regards
   Brian

On 15-Jul-19 14:53, C. M. Heard wrote:
> We've been down that road before. That's how the existing HbH Options Header was supposed to work when it was defined in RFC 2460 (and RFC 1883 before that). Mandating the behavior in those specs did not make it happen (and that's why RFC 8200 relaxed the requirement). Why do you think that mandating the behavior in a new spec (with a new Next Header type) will result in a different outcome?
> 
> Additionally, it is not true that a new Next Header type with Hop-by-Hop behavior is in any way backward compatible. RFCs 1883, 2360, and 8200 specifically disallow that, and existing IPv6 nodes have the assumption that the only Next Header type with HbH behavior is 0x00 "baked in."
> 
> Mike Heard
> 
> On Sun, Jul 14, 2019 at 7:04 PM Pengshuping (Peng Shuping) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     The draft says that “The Options can be shared with the original Hop-by-Hop Options Header.” Not the same. ____
> 
>     __ __
> 
>     Basically, the options are categorized based on their requirements of different processing by being placed into different HBH option headers. In the new HBH header if present, all the carried options will be processed at wire speed instead of being dispatched to CPU.  ____
> 
>     __ __
> 
>     Shuping ____
> 
>     __ __
> 
>     __ __
> 
>     *From:*C. M. Heard [mailto:[email-masked] <mailto:[email-masked]>]
>     *To:* Pengshuping (Peng Shuping) <[email-masked] <mailto:[email-masked]>>
>     *Cc:* Mark Smith <[email-masked] <mailto:[email-masked]>>; 6man WG <[email-masked] <mailto:[email-masked]>>; Lizhenbin <[email-masked] <mailto:[email-masked]>>
>     *Subject:* Re: Comments on draft-li-6man-enhanced-extension-header Sec 2.1____
> 
>     __ __
> 
>     On Thu, Jul 11, 2019 at 7:19 PM Pengshuping (Peng Shuping) <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>         We could do engineering at each option to indicate every router how to treat it. However, that will not be very efficient since each option type needs to be gone through and checked against the preset configuration.____
> 
>     __ __
> 
>     The new header that you propose uses the same options, so how would it be different?____
> 
>     __ __
> 
>     Mike Heard____
> 
>

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 14 Jul 2019 21:22:03 -0700

> configuration in a particular domain, and will not work properly

Yes, operation in a limited domain is the best that can be
expected. In such a domain, there would be no need for
a new variant of the HbH Options Header.

Mike Heard

---

From: Mark Smith <[email-masked]>
Date: Mon, 15 Jul 2019 18:02:55 +1000

> a new variant of the HbH Options Header.

I'd guess one plausible reason for HbH not being supported in the past
in fast path has been that customers haven't required it, and device
manufacturers have never developed it due to lack of customer demand.
Device vendors don't develop something unless they can somehow make it
pay.

If the demand is there, then current HbH EH will eventually be
supported in the fast path.

Regards,
Mark.