Re: Comments on draft-li-6man-enhanced-extension-header Sec 2.1

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

We've been down that road before. That's how the existing HbH Options
Header was supposed to work when it was defined in RFC 2460 (and RFC 1883
before that). Mandating the behavior in those specs did not make it happen
(and that's why RFC 8200 relaxed the requirement). Why do you think that
mandating the behavior in a new spec (with a new Next Header type) will
result in a different outcome?

Additionally, it is not true that a new Next Header type with Hop-by-Hop
behavior is in any way backward compatible. RFCs 1883, 2360, and 8200
specifically disallow that, and existing IPv6 nodes have the assumption
that the only Next Header type with HbH behavior is 0x00 "baked in."

Mike Heard

On Sun, Jul 14, 2019 at 7:04 PM Pengshuping (Peng Shuping) <
[e-mail]> wrote:

> The draft says that “The Options can be shared with the original Hop-by-Hop Options Header.” Not the same.
>
>
>
> Basically, the options are categorized based on their requirements of different processing by being placed into different HBH option headers. In the new HBH header if present, all the carried options will be processed at wire speed instead of being dispatched to CPU.
>
>
>
> Shuping
>
>
>
>
>
> *From:* C. M. Heard [mailto:[e-mail]]
> *Sent:* Friday, July 12, 2019 11:40 AM
> *To:* Pengshuping (Peng Shuping) <[e-mail]>
> *Cc:* Mark Smith <[e-mail]>; 6man WG <[e-mail]>;
> Lizhenbin <[e-mail]>
> *Subject:* Re: Comments on draft-li-6man-enhanced-extension-header Sec 2.1
>
>
>
> On Thu, Jul 11, 2019 at 7:19 PM Pengshuping (Peng Shuping) <
> [e-mail]> wrote:
>
> We could do engineering at each option to indicate every router how to
> treat it. However, that will not be very efficient since each option type
> needs to be gone through and checked against the preset configuration.
>
>
>
> The new header that you propose uses the same options, so how would it be
> different?
>
>
>
> Mike Heard
>