- the document does not yet address uRPF filtering. That's a pretty strong must for us at least (strict uRPF at line rate). In addition, we really want "feasible path strict uRPF" (see RFC3704) as well. We don't really care that much about loose RPF.
ok, I'll see if this fits into the over all... uRPF might be an 'implementation' and out of scope for the doc.
Note: it might be that it's more important for some operators to be able to perform a specific function _to the device_ rather than on any possible interface.
ala juniper loopback filter? or "just drop all protocol FOO on this device" ?
==> this section is too ambiguous to be of any real use. I guess you'll _have_ to specify at least "minimum" minimum performance degradation -- if the vendor can't perform even _that_, it shouldn't claim to be compliant (e.g., a device should be able to deal with 50 address/port based rules with no change to the maximum transfer rate with 20 byte packets).
The performace degradation I was aiming at was: "console access" or "management access" limitations... a 7206 can filter (sort of) 5kpps aimed at the device once you put on recieve-path acls, but it won't be very happy about that filtering and device CPU will shoot to 99% :( That's unacceptable. Filtering "TO THE DEVICE" should have no impact on device CPU/management/console...
==> 32 bit counters are soooo last millenium. I doubt we'd be getting any equipment which doesn't do 64 bit counters. I'd make it a must.
minimum requirements for the capability ...
Yes, but..
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings