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

["C. M. Heard" <[e-mail]>]

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