Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt

[Ole Troan <[e-mail]>]

Tom,

>>>> [LH] The propose does not introduce new hop-by-hop option header, we only introduce new option carried in the existing hop-by-hop option header,
>>> 
>>> Yes, that is exactly what the paragraph from RFC8200 means: it
>>> says "New hop-by-hop options are not recommended".
>> 
>> Blindly reciting rules without also understanding and explaining the intent leads to unintended consequences.
>> 
> RFC8200 also relaxes the requirement that HbH has to be examined by
> every host which I think mitigates some of the concerns that prompted
> the recommendation against new hop-by-hop options.
> 
>> In this particular case, where every hop along the path would need to support it, then that's the exact use case for the hop by hop header.
>> 
> I don't think that every hop in the path would necessarily need to
> support this. It may be the case that traffic engineering is only
> being done on one or two links in the path (backbone links for
> instance) so support is needed there, but nodes at other hops could
> ignore the HbH option.

Right. the HBH is the most efficient way we have to inform an intermediate node, please take a closer look at this packet if you are configured to do so.
There are of course significant deployment issues with HBH and a higher drop probability if you wanted to carry that header outside of the AS.

While the 6man working group can certainly help the authors with those considerations, I believe the work would have to be owned somewhere else.
And it might be a little too early to go into the details of packet formats etc.

Best regards,
Ole