Re: [ipfix-req] Content Based Sampling

[Mark Thibodeau <[e-mail]>]

Sorry...I think I've gotten lost in this email thread.  Here is the scenario I'm thinking about:

Before the metering function, flows are subjected to ACL rules (or filters).  The result of the ACL
lookup is an action (permit/deny) and possibly a Netflow templateID.  If the action is permit, the
flow is added to the flow cache.  The templateID is used to determine what information to store about
the flow.  Many ACL rules can use the same Netflow templateID.

When a flow is exported, the Netflow templateID must be indicated.  AND....maybe some information
about the particular ACL rule that was hit should also be indicated.

The templateID can be indicated by providing a template id or name as you've described below.
However, how do we provide information about the ACL rule?

Are you aware of any routers that currently exported information about the ACL rule that was hit?  I
don't believe Cisco Netflow9 provides this information.

Thanks,
Mark



Mark Fullmer wrote:

> NetFlow v9 is available from Cisco.
>
> It's common practice to use SNMP with NetFlow to query "other"
> information, for example to get the ifName or ifAlias for an
> input/output interface.  Another example is to use BGP to get
> community and AS path information.
>
> mark
>
> On Fri, Mar 21, 2003 at 01:14:21PM -0500, Mark Thibodeau wrote:
> > Are you aware of any router or probe that is currently doing something like this?
> >
> > Thanks,
> > Mark
> >
> > Mark Fullmer wrote:
> >
> > > Yes.  The template ID's have no meaning though, ie you can't tie a template
> > > ID back to a configuration on the exporter, where the configuration might
> > > include ACL's, sampling, or other attributes.
> > >
> > > All that's required is having a template id or name.  Then some other
> > > method (SNMP, etc) can be used to query the exporter for the other
> > > attributes, for example the filter/access-list applied to the metering
> > > process used by the template.
> > >
> > > Exporting other attributes such as access lists, or even ifNames that are
> > > available in other ways (ie SNMP) is not a road we should go down.
> > >
> > > mark
> > >
> > > On Thu, Mar 20, 2003 at 09:12:14AM -0500, Mark Thibodeau wrote:
> > > > Hi Mark,
> > > >
> > > > Are you referring to Cisco-style templates?  In Cisco's v9 format, there is the capability
> > > > for up to 64k templates.  However, on a line card there may be many more ACL rules (or
> > > > filters).  It may not be possible to have a one-to-one mapping between ACL rule and Netflow
> > > > template.  Or, did you have some other scheme in mind?
> > > >
> > > > If communicating the filter rule is required, I agree with Tanja.  Some how the rule will
> > > > need to be encoded in the exported packet.  It could be that we just send a Rule ID.  But,
> > > > I'm not sure how the collector will be able to retrieve the ACL rule by using the exported
> > > > RuleID.
> > > >
> > > > Now I'm wondering......why does the collector need to know which filter rule was used?  What
> > > > application will it use this information for?  If a user wants to know if an ACL filter is
> > > > being hit, they can normally look at the ACL statistics on the node.  I don't see any
> > > > benefit of communicating this information to the collector.  Do you?
> > > >
> > > > Thanks,
> > > > Mark
> > > >
> > > >
> > > > Mark Fullmer wrote:
> > > >
> > > > > I really doubt this group is going to come up with a definition for
> > > > > "ACL" that will get group consensus, let alone encoding it in a
> > > > > packet.
> > > > >
> > > > > A reasonable alternative, IMHO is to have named templates (ie
> > > > > "tcp-port-flows", where the name is user selectable on the
> > > > > exporter.
> > > > >
> > > > > mark
> > > > >
> > > > > On Wed, Mar 19, 2003 at 05:34:55PM +0100, Tanja Zseby wrote:
> > > > > > Hi Mark,
> > > > > >
> > > > > > content-based sampling refers to packet selection functions that take
> > > > > > the packet content into account. So actually it is some form of
> > > > > > filtering. It can also be hash-based sampling where the intention is to
> > > > > > achieve some pseudo random selection.
> > > > > > Maybe you can have a look at the psamp packet selection draft
> > > > > > draft-ietf-psamp-sample-tech-01.txt. There we made a first attempt to
> > > > > > categorize the schemes. Combined schemes (as you explained) are
> > > > > > explicitely allowed.
> > > > > > In my opinion you would need to export both, the filter rule and the
> > > > > > sampling scheme.
> > > > > >
> > > > > > Regards,
> > > > > > Tanja
> > > > > >
> > > > > >
> > > > > > Mark Thibodeau wrote:
> > > > > >
> > > > > >  >Hi,
> > > > > >  >
> > > > > >  >I have some questions about the requirements for sampling.  From
> > > > > >  >requirements 8:
> > > > > >  >
> > > > > >  >....
> > > > > >  >5.2.  Sampling
> > > > > >  >
> > > > > >  >...
> > > > > >  >   selection of one packet can for instance be triggered by its arrival
> > > > > >  >   time (time-based sampling), by its position in the flow (count-based
> > > > > >  >   sampling) or by the packet content (content-based sampling).
> > > > > >  >....
> > > > > >  >
> > > > > >  >What is meant by "content-based sampling"?  Is this basically ACL
> > > > > >  >filtering that tells you whether or not to monitor a flow?
> > > > > >  >
> > > > > >  >If it refers to ACL filtering, then I have some more questions.
> > > > > >  >
> > > > > >  >....
> > > > > >  >6.1.  Information Model
> > > > > >  >....
> > > > > >  >
> > > > > >  >     14. if sampling is used: sampling configuration
> > > > > >  >....
> > > > > >  >
> > > > > >  >If we are using content-based sampling, what information do we want
> > > > > >  >exported with the flow?  Is it basically an ACL rule identifier?  Or do
> > > > > >  >we want to export the entire ACL rule itself?
> > > > > >  >
> > > > > >  >If we need to export a rule identifier or something like that, then
> > > > > >  >there is another situation which presents itself.
> > > > > >  >
> > > > > >  >Let's say there are multiple rules which can cause packets to be
> > > > > >  >monitored.  If we are also doing aggregation, there is the potential for
> > > > > >  >2 or more ACL rules to all point to the same flow record.  When this
> > > > > >  >flow record is exported, which rule identifier should it give?
> > > > > >  >
> > > > > >  >There is also another situation.  An implementation could support
> > > > > >  >simultaneously ACL filtering and packet sampling.  For instance, only
> > > > > >  >the flows that match a certain ACL rule will be monitored.  However,
> > > > > >  >only every 100th packet is sampled.   If this combination is supported,
> > > > > >  >what is the sampling configuration that is exported?  Should we export
> > > > > >  >the rule identifier as well as the sampling rate?
> > > > > >  >
> > > > > >  >Thanks,
> > > > > >  >Mark
> > > > > >  >
> > > > > >  >--
> > > > > >  >
> > > > > >  >****************************************************
> > > > > >  >* Mark Thibodeau, P Eng.
> > > > > >  >* 670 RSP Development - Firmware Designer
> > > > > >  >* Alcatel CID - [phone]
> > > > > >  >* Fax - [phone]
> > > > > >  >* [e-mail]
> > > > > >  >****************************************************
> > > > > >  >
> > > > > >  >
> > > > > >  >
> > > > > >  >--
> > > > > >  >Help        mailto:[e-mail] and say "help" in
> > > > > > message body
> > > > > >  >Unsubscribe mailto:[e-mail] and say
> > > > > >  >"unsubscribe ipfix" in message body
> > > > > >  >Archive     http://ipfix.doit.wisc.edu/archive/
> > > > > >  >
> > > > > >  >
> > > > > >
> > > > > > --
> > > > > > Dipl.-Ing. Tanja Zseby
> > > > > > Fraunhofer Institute FOKUS                    Email: [e-mail]
> > > > > > Kaiserin-Augusta-Allee 31                     Phone: [phone]
> > > > > > D-10589 Berlin, Germany                               Fax:   [phone]
> > > > > > --------------------------------------------------------------------------------------
> > > > > >
> > > > > > "Living on earth is expensive but it includes a free trip around the
> > > > > > sun." (Anonymous)
> > > > > > --------------------------------------------------------------------------------------
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Help        mailto:[e-mail] and say "help" in message body
> > > > > > Unsubscribe mailto:[e-mail] and say
> > > > > > "unsubscribe ipfix" in message body
> > > > > > Archive     http://ipfix.doit.wisc.edu/archive/
> > > > >
> > > > > --
> > > > > Help        mailto:[e-mail] and say "help" in message body
> > > > > Unsubscribe mailto:[e-mail] and say
> > > > > "unsubscribe ipfix" in message body
> > > > > Archive     http://ipfix.doit.wisc.edu/archive/
> > > >
> > > > --
> > > >
> > > > ****************************************************
> > > > * Mark Thibodeau, P Eng.
> > > > * 670 RSP Development - Firmware Designer
> > > > * Alcatel CID - [phone]
> > > > * Fax - [phone]
> > > > * [e-mail]
> > > > ****************************************************
> > > >
> > > >
> > > >
> > > > --
> > > > Help        mailto:[e-mail] and say "help" in message body
> > > > Unsubscribe mailto:[e-mail] and say
> > > > "unsubscribe ipfix" in message body
> > > > Archive     http://ipfix.doit.wisc.edu/archive/
> >
> > --
> >
> > ****************************************************
> > * Mark Thibodeau, P Eng.
> > * 670 RSP Development - Firmware Designer
> > * Alcatel CID - [phone]
> > * Fax - [phone]
> > * [e-mail]
> > ****************************************************
> >

--

****************************************************
* Mark Thibodeau, P Eng.
* 670 RSP Development - Firmware Designer
* Alcatel CID - [phone]
* Fax - [phone]
* [e-mail]
****************************************************



--
Help        mailto:[e-mail] and say "help" in message body
Unsubscribe mailto:[e-mail] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/