On 7/4/21 21:30, Tom Herbert wrote:
On Wed, Apr 7, 2021 at 5:03 PM Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote:
Hi, Tom,
On 7/4/21 12:20, Tom Herbert wrote:
[....]
Given that hosts are the ones creating extensions headers and other
packet formats, hosts have a vested interest in how routers are
dealing with their packets. Even before this document was created, we
have long known that extensions headers might be dropped and have been
working on mitigations to reduce the number of drops which are already
addressing some of the reasons that packets with EH. For instance,
consider draft-hinden-6man-hbh-processing-00; this is a proposal to
limit the number of HBH options to exactly one. The idea is that
routers will make it feasible for routers packets that have HBH
options, with the trade off of specifically limiting the extensibility
of the protocol. The problem is there is no data that indicates this
proposal would have the desired effect; we don't if routers would
start accepting packets that are limited to one HBH option.
What does that proposal have to do with this document?
Because that proposal is ostensibly addressing a perceived reason for
packets being dropped.
That doesn't change what this document is doing *at all*. We're
explaining what operators do at the time of this writing.
If it's not really a problem, then by all means
please chime in on 6man list where the draft is under discussion.
I did raise my concerns during the last 6man minutes. My comments should
be in the meeting minutes.
So my fundamental concern with this draft is that it is an entirely
qualitative description of a well known problem, however a qualitative
No. It is not a well known problem. If you look at
draft-hinden-6man-hbh-processing, itś clear that their assumption is
that limiting the number of EHs or options solves the problem. Whereas
our document essentially notes that to a large extent the problem has to
What exactly does "large extent " mean? Does that mean that at least
50% or some greater than that percentage of drops of packets with EH
were dropped precisely because the header chains were too long?
That's not the topic that this document is addressing.
do with the overall EH-chain length -- it doesn't matter if the
EH-chain: it doesn matter whether you have one long EH, multiple small
ones, one large EH with one large option, one large EH with many small
options, or any combination of them.
Perhaps, but again I ask for either data or references from vendors to
verify that supposition.
Our document contains a reference to the very IEPG presentation that was
done by a vendor.
The fact that youŕe raising this issue and that thereś a belief that
there'ś a clear and easy way to make EHs work probes that itś certainly
not a well known problem.
That is not the only issue that is being addressed. There are also the
suggested limits in RFC8504 for host processing, the mitigation in
RFC8200 to allow intermediate nodes to ignore HBH options, and ICMP
errors in RFC8883 that intermediate nodes drop packets including if
header chains are too long.
Again: what does has to do with this document.
Please read the Abstract and the Disclaimer. That's what this document
is about.
You want this document to be something that it has never been, and has
never been meaning to be.
Thanks,
--
Fernando Gont
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
