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

[Bob Hinden <[e-mail]>]

Mike,

> On Mar 18, 2021, at 9:02 PM, C. M. Heard <[e-mail]> wrote:
> 
>> 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:
>>> 
>>> (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
>>> 
>> 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.
> 
> Yes, that was the idea.

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.
>> 
>> I wasn’t aware of that.  Please explain.
> 
> 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.

Thanks

> 
>>> 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.
> 
> 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.

> 
>>> 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 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.

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


> 
> Mike