[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Terminology harmonization: a proposal
> > n4) Another example of a filtering function could be taking the source
> > and/or destination address, lookup the source/destination AS and filter
> > on the basis of the result. While such a complex filtering function
> > doesn't make sense at the line rate, it may make sense if a sampler is
> > placed in front of a filter to reduce the rate of packets to be
> > processed. In this respect, the text appearing in Nick's draft at the
> > bottom of 3.2 reported below (unavailability of router state to
> > measurement primitives) should be reconsidered.
> > "In order to be able to function at line rates, each measurement
> > primitive take as its input only a packet itself, or quantities
> > that have been calculated from the packet previously by other
> > measurement primitives. Router state is not assumed to be available
> > to the measurement primitives."
> Yes, I have been wondering whether this should be reworked after Peram
> brought up this point a little while ago.
> The reason for excluding router state from the primitive operations
> was arhictectural: we didn't want to assume that the routing state would
> be available to a filter that could be required to operate at line rate.
> (Any comments on this from implementors?)
I agree. At the same time, you could also define some standard operations where
the state is available. For example, it is very easy to program a "filter" operation
on an invalid route and export it to collector. This is useful for a DOS type application.
I think such primitive operations can be classified as "may" instead of "must" so
that it doesnt burden existing hardware.
> But we do assume that routing state, if present in the measuring network
> element, will be available to form the packet reports, so it should be
> feasible to do filtering based on routing state when reports
> are formed i.e. after all the other selection primitives have operated.
> > Maurizio
> > --
> > Maurizio Molina
> > Research Staff member
> > Network Laboratories Heidelberg
> > NEC Europe Ltd.
> > Adenauerplatz 6, D-69115 Heidelberg, Germany.
> > Tel. (49)6221 90511-18 Fax: (49)6221 90511-55
> > e-mail: email@example.com
> > Web: www.ccrle.nec.de
> > --
> > to unsubscribe send a message to firstname.lastname@example.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/psamp/>
> to unsubscribe send a message to email@example.com with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/psamp/>
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.