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

[Tom Herbert <[e-mail]>]

On Tue, Oct 17, 2017 at 9:28 AM, Ole Troan <[e-mail]> wrote:
> 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.
>
Ole,

On one hand, IETF defined extension headers as the extensibility
mechanism of IPv6, but yet on the other hand the message seems to be
to not use them because deployed devices don't correctly support the
protocol. The upshot is that we see proposals in other WGs of stuffing
network layer information into transport protocols (options or
payloads) with the full expectation that intermediate nodes will parse
into the transport layer, process the embedded information, and
possibly even overwrite transport layer information. IMO that is an
architectural abomination and further abandonment of the end to end
model!

> 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.
>
Agreed, but I do think the 6man working group has a vested interest to
make sure that network layer information stays in the network layer.
At some point the information needed is going to be so complex that it
won't be able to be conveyed in any fields of the IP header.

Tom

> Best regards,
> Ole