Subject: Comments on draft-hinden-6man-hbh-processing-00

From: "C. M. Heard" <[email-masked]>
Date: Sat, 13 Mar 2021 16:36:42 -0800

Greetings authors and 6man,

Following IETF 110, I read the draft and reviewed both the slides and the
mailing list traffic in the first half of December 2020, and I am afraid
that I must echo the following comments made by Tom Herbert on Fri, 04
December 2020 01:43 UTC:

*I understand the motivation for this draft, but I don't believe that
forcibly and retroactively restricting a feature in a well deployed
protocol is the right approach to fix the problem.*

It seems to me that the draft has chosen the most disruptive possible way
to restrict the number of options in the HbH header. It seems to me that
the objective could be accomplished in a much less disruptive fashion in
either of the following ways:

(a) specify that nodes that process the HbH options header MAY ignore all
options after the first;
(b) specify that  nodes that process the HbH options header MAY ignore all
options after the first non-PAD option

Alternative (a) is somewhat simpler, but would require re-specifying any
option that requires padding in front if it stands alone inside the HbH
header, As best I am able to determine from a review of the existing HbH
option specifications, IOAM is the only one that is so affected.
Alternative (b) would avoid even that, but it would also require a bit more
work from a compliant node.

Either one of these alternatives  keeps the specification the same EXCEPT
for relaxing the minimum a node is required to meet. Nodes that can process
more options would be allowed to to do. That avoids disruption of systems
that are already deployed and could be useful in limited domains. I do not
see what is gained by requiring nodes to enforce a one-option limit.

I note in passing that the proposal to extend RFC 8504 (IPv6 Node
Requirements) to apply to intermediate systems would have the same general
effect, but would put the simplicity vs capability tradeoff at a different
point.

Mike Heard

---

From: Tom Herbert <[email-masked]>
Date: Mon, 15 Mar 2021 16:32:24 -0600

On Sat, Mar 13, 2021 at 5:37 PM C. M. Heard <[email-masked]> wrote:
> Following IETF 110, I read the draft and reviewed both the slides and the mailing list traffic in the first half of December 2020, and I am afraid that I must echo the following comments made by Tom Herbert on Fri, 04 December 2020 01:43 UTC:
>
> I understand the motivation for this draft, but I don't believe that
> protocol is the right approach to fix the problem.
>
> It seems to me that the draft has chosen the most disruptive possible way to restrict the number of options in the HbH header. It seems to me that the objective could be accomplished in a much less disruptive fashion in either of the following ways:
>
> (a) specify that nodes that process the HbH options header MAY ignore all options after the first;
> (b) specify that  nodes that process the HbH options header MAY ignore all options after the first non-PAD option
>

Hi Mike,

I might suggest that this could be generalized as:

1. An intermediate node may process all HBH options (per RFC8200)
2. An intermediate node may ignore all HBH options (the relaxed
requirement in RFC8200)
3. An intermediate may process a subset of the HBH options. The subset
of options processed for some packet would be precisely the first N
consecutive non-padding options. The remaining options, those after
the first N options would be ignored.

N could be determined per device subject to limits such as the number
of HBH options a node is willing to process, or the byte length of the
EH or IP header chain. Coincident with these requirements should be
some SHOULDs to give guidance to the host creating HBH options: like
an intermediate device that processes HBH options SHOULD process at
least the first 8 non-padding options, and SHOULD process HBH options
that fit within the first 148 bytes of the packet (the value of 8 is
derived from the suggested limit in RFC8504, and the 148 bytes is
based on the assumption that parsing buffers in modern routers are
typically at least 256 bytes, so IPv6 header and 128 bytes of options
is 148 bytes and leaves 106 bytes following HBH EH for router to
parse. If a device fixes N to be one this degenerates to your
proposal. If N=0 that degenerates to #1, if N=inifinity that
degenerates to #2.

This model does imply that hosts should not create option lists that
creates a processing dependency from one option on a later option. The
sending host would need to assume that any number of consecutive
options might be processed, and trailing options ignored. I haven't
looked closely, but I don't think offhand there are any defined
options that would break things if this subset processing happened.
The host would also be motivated to order the options by the
importance that they are processed.

Tom

> Alternative (a) is somewhat simpler, but would require re-specifying any option that requires padding in front if it stands alone inside the HbH header, As best I am able to determine from a review of the existing HbH option specifications, IOAM is the only one that is so affected. Alternative (b) would avoid even that, but it would also require a bit more work from a compliant node.
>
> Either one of these alternatives  keeps the specification the same EXCEPT for relaxing the minimum a node is required to meet. Nodes that can process more options would be allowed to to do. That avoids disruption of systems that are already deployed and could be useful in limited domains. I do not see what is gained by requiring nodes to enforce a one-option limit.
>
> I note in passing that the proposal to extend RFC 8504 (IPv6 Node Requirements) to apply to intermediate systems would have the same general effect, but would put the simplicity vs capability tradeoff at a different point.
>
> Mike Heard
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Thu, 18 Mar 2021 15:53:45 -0700

Mike,

> On Mar 13, 2021, at 4:36 PM, C. M. Heard <[email-masked]> wrote:
> 

Understood, but I don’t think anything will change regarding support for HBH options unless we do something.  I think there is a common quote about doing the same thing and expecting different results.

> 
> It seems to me that the draft has chosen the most disruptive possible way to restrict the number of options in the HbH header.

Yes as compared to what was in RFC2460, but I note that RFC8200 basically said that HBH only have to be supported if a node was configured to support them.   My thinking that supporting one option is much better than none.

> It seems to me that the objective could be accomplished in a much less disruptive fashion in either of the following ways:
> 

I think I would be OK with something like (a).    It’s possible to do this because the HBH header has the information that would enable a node can easily skip the rest.   I don’t think that (b) is that helpful, if a node can skip, it can skip PAD options too.

The proposal would be something like a node SHOULD process the first HBH option in the “fast path”, if there is more than one HBH option, the node MAY process or skip the remaining options.

I note, this change would eliminate the need for 8-octet alignment and would simplify the proposal.

> 
> Alternative (a) is somewhat simpler, but would require re-specifying any option that requires padding in front if it stands alone inside the HbH header, As best I am able to determine from a review of the existing HbH option specifications, IOAM is the only one that is so affected.

I wasn’t aware of that.  Please explain.

> Alternative (b) would avoid even that, but it would also require a bit more work from a compliant node.

Might be better to rework the IOAM option.

> Either one of these alternatives  keeps the specification the same EXCEPT for relaxing the minimum a node is required to meet. Nodes that can process more options would be allowed to to do. That av…

I think are suggesting the proposal be written as a minimum requirement.  A node could do more, but isn’t required to.

I think the biggest issue with anything other than only process one HBH option or any number, is how does the node creating the packets know how many to include in a packet?    I don’t see much use for HBH if the sender puts in more than are liekly be processed.

I suppose, we could create an IANA registry that defines a value for the minimum number of HBH options that SHOULD be processed by all nodes.   Over time if the capabilities of routers increased the number could be increased by an IETF specification.   This would be for Internet wide usage, limited domains could do more with local configuration.

Bob

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 18 Mar 2021 21:02:20 -0700

On Thu, Mar 18, 2021 at 3:53 PM Bob Hinden  wrote:

> On Mar 13, 2021, at 4:36 PM, C. M. Heard wrote:
>
>> It seems to me that the objective could be accomplished in a much less
>> disruptive fashion in either of the following ways:
>>
>> (b) specify that  nodes that process the HbH options header MAY ignore
>> all options after the first non-PAD option
>>
>
> I think I would be OK with something like (a).    It’s possible to do this
> because the HBH header has the information that would enable a node can
> easily skip the rest.   I don’t think that (b) is that helpful, if a node
> can skip, it can skip PAD options too.
>
> The proposal would be something like a node SHOULD process the first HBH
> option in the “fast path”, if there is more than one HBH option, the node
> MAY process or skip the remaining options.
>

Yes, that was the idea.

>> header. As best I am able to determine from a review of the existing HbH

If I am not mistaken, the alignment requirements for the various HbH
options are:

RA: 2n+0
CALIPSO: 4n+2
SMF_DPD: 4n+2 (inferred)
IOAM: 4n
RPL: 2n
Quick-Start: none (inferred)
Minimum Path MTU: 2n or 4n+2 (inferred)

> MPL: 4n+2 (inferred)
Jumbo Payload: 4n+2
IP_DFF: 4n+2 (inferred)

Some of the specifications do not explicitly specify the alignment
requirements; in those cases I have inferred the alignment requirements
from the diagrams.

The HbH header is aligned to an 8-octet boundary and starts with two
one-octet fields (Next Header and Hdr Ext Len). An option with alignment
requirements none, 2n, 4n+2,  8n+2, or none can be placed immediately after
Next Header and Hdr Ext Len with no pads. Of the above options, the only
one that does not meet that requirement is IOAM. Note that I have inferred
an alignment requirement of "none" for Quick-Start since the same option
data format is used for IPv4 and IPv6; however, 4n would also be a
reasonable inference.

> Alternative (b) would avoid even that, but it would also require a bit
>>> more work from a compliant node .
>>>
>>

That is a possibility, since the spec is still unpublished; but how hard is
it to skip either two PAD1's or a PADn with n=0?

> I think [you] are suggesting the proposal be written as a minimum
> requirement.  A node could do more, but isn’t required to.
>
> I think the biggest issue with anything other than only process one HBH
> option or any number, is how does the node creating the packets know how
> many to include in a packet?    I don’t see much use for HBH if the sender
> puts in more than are liekly be processed.
>
> I suppose, we could create an IANA registry that defines a value for the
> minimum number of HBH options that SHOULD be processed by all nodes.   Over
> time if the capabilities of routers increased the number could be increased
> by an IETF specification.   This would be for Internet wide usage, limited
> domains could do more with local configuration.
>

What I had in mind was a minimum of one option with the ability to do more
via local configuration.

Mike

---

From: Tom Herbert <[email-masked]>
Date: Fri, 19 Mar 2021 08:05:51 -0700

> Yes as compared to what was in RFC2460, but I note that RFC8200 basically said that HBH only have to be supported if a node was configured to support them.   My thinking that supporting one option…

Bob,

That's not entirely clear to me. The major problem with HBH options is
that some intermediate devices will summarily drop packets with the
HBH EH or relegate them to a slow path and in either case that makes
HBH with any number of options difficult to deploy. If intermediate
nodes followed the relaxed requirement of RFC8200 then that would be a
major step towards making them deployable (there's also the issue of
intermediate arbitrarily dropping packets because the "header chain"
is too big). Assuming that this issue is overcome, then it makes sense
to set some guidelines on how many HBH options should be processed,
the recommendation should be something between 1 and 500 (upper limit
based on a MTU sized packet filled with two byte options). Personally,
I believe eight is reasonable recommendation to support and can be
feasibly parsed by in hardware applying latest techniques and should
allow sufficient extensibility for the next 25 years.
> I think I would be OK with something like (a).    It’s possible to do this because the HBH header has the information that would enable a node can easily skip the rest.   I don’t think that (b) is…

As I mentioned, the generalization of these rules is that a node can
process the partial list of consecutive options up to N of them.
Assuming that processing a partial list of HBH options is viable, then
the guidance would be for what N should default to (where one is a
possible value and eight is another as I stated above)

> I note, this change would eliminate the need for 8-octet alignment and would simplify the proposal.
I think that is only a simplification if the RFC8200 requirement was
changed to hosts MUST send at most one HBH option, otherwise padding
is still an issue and intermediate devices. The padding options
themselves could be constrained to help implementations, a requirement
could be set that the amount of padding between two non-padding
options could be less than eight octets in length and only one PADN or
PAD1 can be set between non-padding options.

> I think are suggesting the proposal be written as a minimum requirement.  A node could do more, but isn’t required to.
I think we also need guidance on minimum requirements of byte length
of options, EH, and header chains (lest intermediate nodes drop
packets with HBH for those reasons)

> I think the biggest issue with anything other than only process one HBH option or any number, is how does the node creating the packets know how many to include in a packet?    I don’t see much use for HBH if the sender puts in more than are likely be processed.

As I said, from a host POV I'm much less worried about whether all the
nodes process HBH; in fact, in some scenarios the HBH options might be
more or less targeted to some subset of intermediate nodes (for
instance the first upstream router that processes a FAST ticket, and
that might be intentionally not processed by other nodes in the path).
But, if even one node in the path drops the packet because it doesn't
like HBH then the whole mechanism is usable on that path.
> I suppose, we could create an IANA registry that defines a value for the minimum number of HBH options that SHOULD be processed by all nodes.   Over time if the capabilities of routers increased th…

Yes, that limit and limits on header lengths seem to be needed to move
HBH forward.

Tom

---

From: Bob Hinden <[email-masked]>
Date: Mon, 29 Mar 2021 09:39:50 -0700

Mike,

> On Mar 18, 2021, at 9:02 PM, C. M. Heard <[email-masked]> wrote:
> 

OK

> 
>>> Alternative (a) is somewhat simpler, but would require re-specifying any option that requires padding in front if it stands alone inside the HbH header. As best I am able to determine from a review of the existing HbH option specifications, IOAM is the only one that is so affected.
>> 
> If I am not mistaken, the alignment requirements for the various HbH options are:
> 
> RA: 2n+0
> CALIPSO: 4n+2
> SMF_DPD: 4n+2 (inferred)
> IOAM: 4n
> RPL: 2n
> Some of the specifications do not explicitly specify the alignment requirements; in those cases I have inferred the alignment requirements from the diagrams.
> 
> The HbH header is aligned to an 8-octet boundary and starts with two one-octet fields (Next Header and Hdr Ext Len). An option with alignment requirements none, 2n, 4n+2,  8n+2, or none can be placed immediately after Next Header and Hdr Ext Len with no pads. Of the above options, the only one that does not meet that requirement is IOAM. Note that I have inferred an alignment requirement of "none" for Quick-Start since the same option data format is used for IPv4 and IPv6; however, 4n would also be a reasonable inference.

Thanks

> 
>>> Alternative (b) would avoid even that, but it would also require a bit more work from a compliant node .
>> 
> That is a possibility, since the spec is still unpublished; but how hard is it to skip either two PAD1's or a PADn with n=0?

I think it’s better to just modify it now.

>> I think [you] are suggesting the proposal be written as a minimum requirement.  A node could do more, but isn’t required to.
>> 
> What I had in mind was a minimum of one option with the ability to do more via local configuration.

I will discuss with my co-author and we will work on an update to the draft.    I think an approach like this can work and meet the goals of what we are trying to achieve.   That is, make HBH options usable.

Bob

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Mar 2021 14:03:45 -0700

Hi Mike, et al.,
I wanted to chime in on what I see as the IOAM HbH challenge.
IOAM, in my opinion, is the combination of two major elements:

   - conveying to a node the content of telemetry information to generate
   - collecting and transporting that telemetry information

The former is done by the fixed-size IOAM Trace-Options header defined in
Section 5.4.1 draft-ietf-ippm-ioam-data
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/?include_text=1>
.
The latter referred to as IAOM Trace-Option type, can be achieved using
different trace-option techniques:

   - pre-allocated
   - incremental
   - Direct Export
   <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/>
   - using the Hybrid Two-Step
   <https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/>

The first two collect the telemetry information in the same packet that
carries the IOAM Trace-Options header. The other two use specially
generated packets to collect and transport the telemetry information. I
wanted to mention these methods to point out that the IOAM footprint in HbH
doesn' have to be 4n and it can be limited to the length of the IOAM
Trace-Options header.
I hope that this information is of use for the discussion.

Regards,
Greg

On Thu, Mar 18, 2021 at 9:02 PM C. M. Heard <[email-masked]> wrote:

>> I think I would be OK with something like (a).    It’s possible to do
>> this because the HBH header has the information that would enable a node
>> can easily skip the rest.   I don’t think that (b) is that helpful, if a
>> node can skip, it can skip PAD options too.
>>
> That is a possibility, since the spec is still unpublished; but how hard
> is it to skip either two PAD1's or a PADn with n=0?
>

---

From: [email-masked]
Date: Mon, 29 Mar 2021 23:28:19 +0200

> On 29 Mar 2021, at 23:03, Greg Mirsky <[email-masked]> wrote:
> 
> The first two collect the telemetry information in the same packet that carries the IOAM Trace-Options header. The other two use specially generated packets to collect and transport the telemetry information. I wanted to mention these methods to point out that the IOAM footprint in HbH doesn' have to be 4n and it can be limited to the length of the IOAM Trace-Options header.

It would be interesting to hear from implementors if the 64-bit alignment offers any benefit at all.

From the implementations I work on packets aren't arriving in buffers 64-bit aligned anyway (variable length L2 headers) so it just doesn't offer any benefit.

Best regards,
Ole