Re: [Tsv-art] [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

[Tom Herbert <[e-mail]>]

On Wed, Apr 7, 2021 at 10:16 PM Fernando Gont <[e-mail]> wrote:
>
> Hi, Tom,
>
> On 8/4/21 00:51, Tom Herbert wrote:
> > Fernando,
> >
> > I will also point that the data of RFC7872 is not consistent with
> > header length being the top reason for drops. If I'm reading the data
> > correctly, the HBH options are drop at about 3-4 time that rate that
> > Destination options in that analysis. Since there both the same size
> > (8 bytes), it seems that the majotiy of HBH options are being dropped
> > because they are hop-by-hop options, not because the header chain is
> > too long. This makes sense, because of the original requirement that
> > all intermediate nodes must process hop-by-hop options, and we know
> > many vendors didn't implement then. That requirement was relaxed in
> > RFC8200, and so we'd expect drop rates to drop as nodes move to
> > ignoring HBH options instead of blindly dropping them.
>
> Again: this document is not trying to explain the numbers in RFC7872.
> PLease do read the abstract and the disclaimer, because you keep trying
> to have this document do something that it's not meant to do.
>
Fernando,

>From the draft:  "The Hop-by-Hop Options header has been particularly
challenging since in most circumstances, the corresponding packet is
punted to the control plane for processing.  As a result, operators
usually drop  IPv6 packets containing this extension header."

"usually" implies that most routers are dropping IPv6 packets with
Hop-by-Hop Options. However, no evidence for that is offered and in
fact the best data available, RFC7872,  shows the drop rate is less
than 50% six years ago well before the mitigation in RFC8200. IMO,
this wording is potentially a mischaracterization and an exaggeration
of the problem.

> You should also note that the possible impact on devices is dependent on
> the EH chain length. However, the decision to drop packets need not be
> based on the EH length -- among other reasons, because such information
> might not be readily available.
>
> Folks running a network can't be bothered digging into how many bytes of
> EHs each device they use can handle, and then be expected to figure out
> if there'ś any way to let only packets of shorter EH-chain lengths
> through. There are other problems to tackle day-to-day -- and this one
> is not even a problem: If I have no practical requirement to support
> them, and on the other hand there'ś risk in supporting them, I don't
> need to explain what my decision will be. You'll have a hard time
> explaining your manager or CEO why your network was brought down for
> supporting something you didn't need to support ("didn't need" == "the
> folk that pays the bill didn't ask for or care about it")..

Sure, tell me, as a host stack developer, what at reasonable minimum
length is for an IP header chain and I'll fix the packets I'm sending
so that the operators don't need to be bothered with this.

Tom

>
> Thanks,
> --
> Fernando Gont
> e-mail: [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>