C. M. Heard wrote on 24/11/2018 16:14:
On Sat, Nov 24, 2018 at 7:37 AM Nick Hilliard <nick@xxxxxxxxxx> wrote:
C. M. Heard wrote on 23/11/2018 16:20:
transit operators would generally take the view that any data-plane
packet which needs to be put through a slow path will be rate limited up
to 100% loss. We can argue endlessly at the IETF about the pros and
cons of this from a protocol development and management point of view
but at the end of the day, transit operators have networks to run, and
there is a jarring disparity between data-plane forwarding speed and
control-plane processing capacity. If you expect one to bleed into the
other, something needs to give. This is often going to be
silicon-specific; what is slow-pathed on one platform may not be
slow-pathed on another, so generalised statements are difficult in this
situation.
It's not clear to me what that has to do with the specific comments
that I made (and that you elided). I would understand if I had brought
up handling of, say, HbH options rather than default drop policies for
unknown (and experimental) header types. Perhaps you could clarify.
hm yes, it was a bit obtuse. What I was trying to get at (and
completely failed to achieve) was:
1. that EHs are largely unusable anyway, so if this draft makes some
types slightly more unusable, that isn't going to make much of a
practical difference. RFC7872 suggests failure rates of ~30% - 50% for
fragment headers. Once you're in this territory, nothing you can do
will make things any worse.
2. transit operators don't like filtering stuff. They will filter
traffic if and only if that traffic is a nuisance or forms a threat to
the operation of their networks, and:
My primary objection is to the advice that says discard unknown
EHs and upper-layer protocols by default. That advice needs to
be more nuanced -- as is the advice for unknown option types
given in Sec. 4.4.5, I see no reason why these cases should
get different advice.
....3. Any recommendation that the IETF makes in this area may, or may
not, be taken as input into a decision machine, the result of which will
be to filter, or rate limit, or to forward. From this perspective, the
documentation needs to observe and make suggestions.
Nick
