[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: draft-morrow-filter-caps-00 comments



A question/comment below on 2.1.3

donald.smith@qwest.com giac 

> -----Original Message-----
> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On 
> Behalf Of Christopher L. Morrow
> Sent: Monday, March 07, 2005 12:37 AM
> To: Pekka Savola
> Cc: opsec@ops.ietf.org
> Subject: Re: draft-morrow-filter-caps-00 comments
> 
> 
> getting started reading comments...
> 
> On Sun, 6 Mar 2005, Pekka Savola wrote:
> 
> > Hi,
> >
<SNIP>

> > 2)
> >
> > 2.1.3  Ability to Filter Traffic To the Device - Minimal Performance
> >        Degradation
> >
> > ==> 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...

Does managment access include control plane access?
IE while filtering the device must
maintain the ablity to receive and send updates on the control plane. A
specific example would be after adding
the filter the system can not start dropping BGP updates.

<SNIP>