On Sat, Nov 24, 2018 at 7:37 AM Nick Hilliard <nick@xxxxxxxxxx> wrote: > C. M. Heard wrote on 23/11/2018 16:20: > > while promoting a **/_default deny_/** policy with respect to unknown > > extension headers, experimental extension headers, and experimental > > options. If every transit router followed that advice, it would be > > impossible to transmit packets containing these things across the open > > Internet. It is especially egregious to dispense that advice for > > unknown extension headers, since that would severely impede deployment > > of any new extension headers OR any new transport protocols in the open > > Internet (as the document itself notes, unknown extension headers are > > indistinguishable from unknown upper-layer protocol headers). This part > > of the document's advice does nothing to improve the situation reported > > in RFC 7872; if anything, it makes the situation worse. It certainly > > will not make the Internet work better. > > 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. > Transit operators are going to make their own decisions about what to do > about packet filtering, and take any specific recommendation in an ID > like this with a grain of salt. In that respect, this document needs to > be seen as a store of information to help people make informed decisions > about what to do rather than being a prescriptive list. Agreed, that's the most useful part of the document. But it does in addition give specific advice, and that advice should be reasonable as a default. 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. Mike Heard
