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

[Greg Mirsky <[e-mail]>]

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 <[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.
>
> 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.
>
>
>> 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?
>
> 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.
>
> Mike
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>