[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
interface.


ala juniper loopback filter? or "just drop all protocol FOO on this
device" ?

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
CPU/management/console...

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 ... 

Yes, but..

- are there actually any vendors which don't implement _any_ counters at all?
- 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