[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: psamp filtering
See question inline below,
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com] On
> Of Maurizio Molina
> Sent: Tuesday, November 30, 2004 5:34 AM
> To: Duffield,Nicholas G (Nick)
> Cc: firstname.lastname@example.org
> Subject: Re: psamp filtering
> email@example.com 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
> >don't think this is what is intended. (In any case, PSAMP can
> >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
> >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)
> >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
> 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,
> >If order is not specified, we might want to replace
> >"AND operations are possible by concatenating filters"
> >"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
> part of your text to leave the door open to implementation of
> filters in "one step".
> My proposal:
> AND operations are possible by concatenating filters through the use
> the STREAM ID (see sec. 7.1 and 8). In this case, the ordering in
> the filtering happens is implicitly defined (outer filters come after
> inner filters). However, as long as the concatenation is on filters
> the result of the cascaded filter is independent from the order, but
> order MAY be important for implementation purposes, as the first
> will have to work at a higher rate. In any case, an implementation is
> constrained to respect the filter ordering, as long as the result is
> same, and it MAY even implement the composite filtering in filtering
> one single step.
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
> >Finally, it was suggested to me at IETF 61 that the current text in
> >framework draft (it speaks of match/mask operations) should be
> >with the text from the sampling draft. I can do this once the latter
> >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.