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

["Barry Raveendran Greene" <bgreene@cisco.com>]

> > 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).
> 
> Sigh.  We went over that.   I guess it's time to revisit.  
> I'm having lunch
> with Scott Poretsky of the benchmark methodology working 
> group today.... I'll get his take.
> 
> Bottom line, I think, is that the degredation that is 
> acceptable will vary from situation to situation & what's 
> needed is for the operator to know what their requirements 
> are and to have some way of knowing what the degredation 
> pattern for a particular device is going to be.

Actually, I think we have enough data and understanding of the problem so
that we can create a benchmark document on packet filtering performance.
Right now it is all vendor FUD measurements - not providing the operators
with the data they need. This is simular to the pre-forwarding benchmark -
where vendors were putting a million prefixes into a BGP RIB and saying "see
it works" (when only a fraction of those prefixes could fit in a FIB on the
ASIC).

So let Scott know that there is support for an "packet policing benchmark."
This would include the classification (matching a policy rule), action
phases (drop, redirect, rate limit, recolor, etc.), and accounting phase
(counters and other data). This would allow operators, professionsal
evaluators, and vendors to do apple to apple tests.