Re: Terminology harmonization: a proposal

[Peram Marimuthu <peram@cisco.com>]

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

Peram

>
>
> 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.
>
> Nick
>
>
> > 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: molina@ccrle.nec.de
> > Web: www.ccrle.nec.de
> >
> > --
> > to unsubscribe send a message to psamp-request@ops.ietf.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 psamp-request@ops.ietf.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 psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>