Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)

[Fernando Gont <[e-mail]>]

On 13/7/20 15:11, Tom Herbert wrote:
> On Mon, Jul 13, 2020 at 11:01 AM Fernando Gont <[e-mail]> wrote:
>>
>> On 10/7/20 15:32, Toerless Eckert wrote:
>>> IMHO: See my email earlier in the thread about punting stuff to slow-path, especially when/before
>>> you figure out that you should have just ignored something at linerarte.
>>>
>>> Aka: not sufficiently prescriptive RFCs + bad implementations == extension header based features killed in deployments.
>>
>> Indeed. And add to that that the EH structure itself seems to be rather
>> unfriendly with some popular hardware architectures. (unless with "not
>> sufficiently prescriptive RFCs" you are meaning to set the maximum
>> EH-header chain length to some sane value that folks might agree to
>> comply with).
>>
> 
> RFC8504 implicitly does that for number of Hop-by-Hop or Destination
> options in a packet:
> 
> "A host MAY impose a limit on the maximum number of non-padding
> options allowed in the destination options and hop-by-hop extension
> headers.  If this feature is supported, the maximum number SHOULD be
> configurable, and the default value SHOULD be set to 8."
> 
> The default value of eight was derived from the number of already
> defined options, extrapolation of new options that might be defined
> and deployed, and discussions with some HW vendors that they can
> efficiently process a small number of TLVs (as opposed to hundreds in
> a packet that are possible without a limit).

Kudos to RFC8504 and authors for that- That said, given that options may 
have a rather unlimited length, is that enough? It would seem to me that 
the most important thing is that E-H header length, as opposed to the 
length of individual options, or ther number of options...

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492