Subject: RE: psamp filtering

From: <[email-masked]>
Date: Fri, 3 Dec 2004 13:12:46 -0500

Maurizio,

See question inline below,

Nick

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Maurizio Molina
> Sent: Tuesday, November 30, 2004 5:34 AM
> To: Duffield,Nicholas G (Nick)
> Cc: [email-masked]
> Subject: Re: psamp filtering
> 
> [email-masked] wrote:
> 
> >In the sampling techniques draft:
> >
> >	6.1 Field Match Filtering
> >
> >    	We here define a basic Filtering schemes based on the IPIFIX
> >    	flow definition. With this method a packet is selected if a
> >    	specific field in the packet equals a predefined value. Possible
> >
> >    	filter fields are all IPFIX flow attributes specified in [IPFIX-
> >    	INFO]. Further fields can be defined by vendor specific
> >    	extensions.
> >    	A packet is selected if Field=Value. Masks and ranges are only
> >    	supported to the extend to which [IPFIX-INFO] allows them e.g.
> >    	by providing explicit fields like the netmasks for source and
> >    	destination addresses. AND operations are possible by
> >    	concatenating filters. OR operations are not supported with this
> >
> >    	basic model. More sophisticated filters (e.g. supporting
> >    	bitmasks, ranges or OR operations etc.) can be realized as
> >    	vendor specific schemes.
> >
> >As it stands now, this text might give the impression that AND
> >operations are accomplished by composing a number of PSAMP selectors,
> >each being primitive and corresponding to filtering on a single
field. I
> >don't think this is what is intended. (In any case, PSAMP can
currently
> >only combine one filter with one sampling operation at present).
> >
> My understanding is that through the STREAM ID you can have multiple
> concatenation, and even a filter + filter concatenation (and in this
> case the order is intrinsically specified).
> However, I admit that from the TOC only it looks like that the only
> possible composition is Cascaded Filtering->Sampling or
> Sampling->Filtering (se. 8.1). But if you read the text before, it
> states that it is just an example.
> 
> >
> >
> >Also, "concatenation" implies that an order amongst the basic filters
is
> >to be specified.
> >
> Correct, but the result will then be independent of the  order.
> 
> > As Matt Grossglauser has pointed out, this might be
> >useful if one wants to put a "quick" filter (e.g. on port number)
first,
> >to reduce the packet rate down for a "slow" filter (e.g. on routing
> >state) following. So do we want to require ordering of filters within
> >the combination?
> >
> See above: I think that if you specify a cascaded filter via the
STREAM
> ID, ordering is implicitly defined, but the result will then be
> independent of the  order.
> 
> > Or would some implementors want to implement some or
> >all combinations as a single composite mask/match across fields,
without
> >ordering....?
> >
> >If order is not specified, we might want to replace
> >
> >"AND operations are possible by concatenating filters"
> >
> >with
> >
> >"AND operations are possible by specifying multiple basic field match
> >Filters, the packet being selected if would be selected by all the
> >specified filters. The resulting combination is viewed as a primitive
> >PSAMP Selector."
> >
> >
> I think that if we go for your proposal, we have to ensure that
> IPFIX-INFO supports it.
> I'd rather stick to the old text for SPECIFYING a filter. Then  I'd
add
> part of your text to leave the door open to implementation of
composite
> filters in "one step".
> My proposal:
> 
> AND operations are possible by concatenating filters through the use
of
> the STREAM ID (see sec. 7.1 and 8). In this case, the ordering in
which
> the filtering happens is implicitly defined (outer filters come after
> inner filters). However, as long as the concatenation is on filters
only,
> the result of the cascaded filter is independent from the order, but
the
> order MAY be important for implementation purposes, as the first
filter
> will have to work at a higher rate. In any case, an implementation is
not
> constrained to respect the filter ordering, as long as the result is
the
> same, and it MAY even  implement the composite filtering in filtering
in
> one single step.
> Maurizio

Do you view the concatenation as a composite selector, with each
component filter a primitive selector? If so, the text in the framework
document Section 5.5 needs to include this as an example of a composite
selector.

> 
> >Finally, it was suggested to me at IETF 61 that the current text in
the
> >framework draft (it speaks of match/mask operations) should be
replaced
> >with the text from the sampling draft. I can do this once the latter
is
> >finalized.
> >
> >Comments?
> >
> >Nick
> >
> >
> >
> >--
> >to unsubscribe send a message to [email-masked] 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-masked] 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-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>

---

From: Maurizio Molina <[email-masked]>
Date: Wed, 08 Dec 2004 14:58:07 +0000

[email-masked] wrote:

>component filter a primitive selector?
>
Yes

> If so, the text in the framework
Since 5.5  mentions that they are only examples, it is not strictly 
necessary. But a third explicit example with filter+filter can be added, 
if you feel it clarifies.
Maurizio