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