[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-morrow-filter-caps-00 comments
On Mon, 7 Mar 2005, Christopher L. Morrow wrote:
- 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.
I'd try to bake it in _somewhere_, because it's very, very different
having to create manual ACLs to do anti-spoofing, vs. sane kind of
strict uRPF (e.g., what feasible paths in RFC3704 is, also works for
asymmetric and multihomed).
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
ala juniper loopback filter? or "just drop all protocol FOO on this
Sorry for being too terse. What I was referring to was that some
operators might see some capability (e.g., being able to log the
packet headers) more important when it's applied to the device or for
the transit traffic.
E.g., if an implementation could not provide 100% line rate ACLs for
10gbit/s interfaces, but could provide sufficient filtering for the
management access ("to the device"), that might be OK for an operator.
==> 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
Agree that filtering to the device should not have this impact.
However, I think the text probably needs to be more explicit about the
real minimum goals.
==> 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 ...
- are there actually any vendors which don't implement _any_ counters
- if everyone implements the counters, the only thing relevant to the
operators is whether the counters are 32 or 64 bit. The current
capability does not offer anything tangible for a CFP to distinguish
between implementations using 32 or 64 bits, because all will claim
compliance if 32 is the minimum.
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings