Subject: One comment to <draft-hinden-6man-hbh-processing-01>

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 12 Nov 2021 04:08:38 +0000

Dear WG,

I have one comment to <draft-hinden-6man-hbh-processing-01>.

Section 6 says "new Hop-by-Hop options should not be variable size that could extend beyond what can be executed in the Fast Path."
I think there are problems in this proposal.
(1) It bounds the two things "variable size" and "beyond ... Fast Path" unnecessary.
(2) By "should not be variable size" it put a hard boundary for the extensibility of an Option.

I would suggest the following for a smooth way toward the target of Fast-Path friendly Option design:
-----------NOW text-------------------------------------------------
(New Hop-by-Hop options SHOULD have the following characteristics):
   *  Fixed size in 8-octet units.  Specifically any new Hop-by-Hop
      options should not be variable size that could extend beyond what
      can be executed in the Fast Path.
-----------NEW text-------------------------------------------------
(New Hop-by-Hop options SHOULD have the following characteristics):
   *  Fixed size indicated by Option Type. That is, any new Hop-by-Hop
      option should have a fixed size indicated by the Option Type,
          and the Option Length value should be no less than this value.
          When Option Length value is bigger than this value, the nodes
          processing this option MAY skip the rest of the option data that
          is beyond the fixed size.

(I am aware that this document will be discussed in the 6man-v6ops joint session later today, but I may not be able to attend due to another meeting I have to attend. So I raise it now here)

Best Regards,
Jingrong

---

From: Bob Hinden <[email-masked]>
Date: Fri, 12 Nov 2021 08:22:11 -0800

Jingrong,

Thanks for the feedback.

> On Nov 11, 2021, at 8:08 PM, Xiejingrong (Jingrong) <[email-masked]> wrote:
> 
> Dear WG,
> 
> 
> 

I suspect the text can be improved.   The tradeoff here is reducing some flexability in order to get more  fast path implementations and deployment.

Note that the using the word “SHOULD” means to do this unless there is a good reason to do something different.

In my view, the simpler each new option is to process, it is more likely it will see widespread implementation.

>           is beyond the fixed size.

If I understand what you are saying, have a HBH Option be longer than the value indicated in “Opt Data Len” field, would be a protocol violation.   It would be a change to all Extension headers to change the meaning of this field and encode the length of options as part of the Option Type.  See Section 4.2 of RFC8200.

Bob

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

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 12 Nov 2021 13:29:43 -0800

Hi,

I find the following statement odd (I do prefer the original text though) “When Option Length value is bigger than this value, the nodes processing this option MAY skip the rest of the option data that is beyond the fixed size.”
Rather than reading a part of the option, the option should be skipped all together.

Cheers,
Jeff

> On Nov 11, 2021, at 20:09, Xiejingrong (Jingrong) <[email-masked]> wrote:
>

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 15 Nov 2021 03:15:34 +0000

Hi Bob,

Let me try to rephrase my point.

The <draft-hinden-6man-hbh-processing-01 > says "Specifically any new Hop-by-Hop options should not be variable size". 
This means that, the size of a new Hop-by-Hop option is determined by the "Option Type" using a [Lookup-table]. 
For an implementation, the [Lookup-table] contains the "Option Type" and the non-variable size of the Option.
When receiving a packet with HBH, an implementation *has to determine what to do* when the "Opt Data Len" in the packet is *not* the same as the "non-variable size" in [Lookup-table].

Particularly, when the "Opt Data Len" in the packet is *larger* than the "non-variable size" in the [Lookup-table], an implementation may have the following options:
Option-1: Discard the packet.
Option-2: Skip over this option (using the Opt Data Len field for skipping, not using the non-variable size in the lookup-table).
Option-3: Process the option as much as it can, and when it can not process the option in the Fast Path, it MUST behave as if it does not recognize the Option Type.

My point it that, the action for this detailed processing (exception processing) should be specified in the document, and the best choice is [Option-3].
However, the "Specifically any new Hop-by-Hop options should not be variable size" in the draft is not a clear specification, and may lead to an implementation to choose [Option-1].
Once an implementation choose [Option-1], it will bring a hard bound for the extensibility of an Option.
Suppose there is a very widespread HBH-Option-X deployed in an network with different implementations using [Option-1].
When the network operator want to try an extension of HBH-Option-X (using additional fields and larger Opt Data Len) by one implementation, the packet will be discarded by the nodes running other implementations.

My additional point is that, the extensibility of an Option is very important, though I also understand motivation of this draft to make HBH option useful by making it simple for Fast-Path processing.
The choice [Option-3] above not only keeps the Fast-Path processing simple, but also add the extensibility for future !

[Lookup-table]: 
----described in the <draft-hinden-6man-hbh-processing-01>----
   A possible approach to implementing this is to maintain a lookup
   table based on Option Type of the IPv6 options that are supported in
   the Fast Path.  This would allow for a node to quickly determine if
   an option is supported and can be processed.  If the option is not
   supported, then the node processes it as described in Section 5.2 of
   this document.

Regarding your point "In my view, the simpler each new option is to process, it is more likely it will see widespread implementation."
I think I not only understand by also agree with this point.

Regarding your point "If I understand what you are saying, have a HBH Option be longer than the value indicated in “Opt Data Len” field, would be a protocol violation."
I think this understanding is incorrect. As rephrased above, I was saying the "Opt Data Len" in a packet is larger than the "the non-variable size" indicated by the "Option Type" in the Lookup-table. 

Best Regards,
Jingrong

-----Original Message-----
From: Bob Hinden [mailto:[email-masked]] 
Sent: Saturday, November 13, 2021 12:22 AM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: One comment to <draft-hinden-6man-hbh-processing-01>

Jingrong,

Thanks for the feedback.

Bob

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 15 Nov 2021 03:32:17 +0000

Hi Jeff,

Thanks for your point.
I have rephrased my point in the reply to Bob, and I think the problem is not a choice between “Skip part of the option” or “Skip the whole option all together”, but a detailed processing specification to guide implementation with wider options to consider. Please let me know your further points. Would be very much appreciated.

Jingrong

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Saturday, November 13, 2021 5:30 AM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: [email-masked]
Subject: Re: One comment to <draft-hinden-6man-hbh-processing-01>

Hi,

Cheers,
Jeff

On Nov 11, 2021, at 20:09, Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>> wrote:
When Option Length value is bigger than this value, the nodes
          processing this option MAY skip the rest of the option data that
          is beyond the fixed size.

---

From: Fred Baker <[email-masked]>
Date: Sun, 14 Nov 2021 19:51:43 -0800

The thing I would respond with is that the intermediate device finds it too heavy. It wants to “do something” or “not do something”; and if it is to do something, it needs to be able to do it again and again for each successive packet at line rate. That comes down to “drop it” or “ignore it”, because anything else is a DDoS vector.

Sent using a machine that autocorrects in interesting ways...

> On Nov 14, 2021, at 7:32 PM, Xiejingrong (Jingrong) <[email-masked]> wrote:
> 
> 
> Hi Jeff,
>  
> Thanks for your point.

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 15 Nov 2021 04:24:31 +0000

Hi Fred,

In my understanding, the selection to “Do something” or “Not do something” is determined by the Lookup-table indexed by the “Option Type”.

For “Not do something” case, the act-bits (00/01/10/11) is guiding the implementation to “drop it” or “ignore it”, and there is no problem here.

For “Do something” case, there is still some “detailed-processing” to be specified when the “Opt Data Len” of a packet is larger or smaller than the non-variable size in the Lookup-table.  If the “detailed-processing” is not properly specified, it will lead to incorrect or inconsistent implementations, and this is the problem I am raising for discussion.

Best Regards,
Jingrong

From: Fred Baker [mailto:[email-masked]]
Sent: Monday, November 15, 2021 11:52 AM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>; [email-masked]
Subject: Re: One comment to <draft-hinden-6man-hbh-processing-01>

On Nov 14, 2021, at 7:32 PM, Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeff,

Thanks for your point.

Jingrong

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Saturday, November 13, 2021 5:30 AM
To: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: One comment to <draft-hinden-6man-hbh-processing-01>

Hi,

Cheers,
Jeff

[email-masked]<mailto:[email-masked]>