Subject: Re: [ipfix-req] Re: IPFIX Requirements Questions

From: [email-masked]
Date: Tue, 01 Oct 2002 12:08:58 -0400

Ganesh Sadasivan wrote:
> 
> Just taking the topic of DP alone.
> 
> >
> > > >
> > > >         I think this points to an area of weakness for us (IPFIX). We are
> > > >         having a hard time having a discussion.
> > > >
> > > >         Lets say that DP = "Distinguising Properties". Where DP is
> > > >         the set of fields and functions, etc... that are used
> > > >         to define a flow. Lets assume for now that the set of possible
> > > >         fields and functions, etc... is fully defined somewhere
> > > >         (it's not, but assume it is for now.).
> > > >
> > > >         If we require that each flow can be mapped to its DP
> > > >         then the discussion moves to how that happens.
> > > >
> > > >         There are many ways. Here are a few which come to mind...
> > > >
> > >
> > > Does it matter how the DP is identified & send (whether with each flow or  split
> > > across flow & control or otherwise) is sent, from a req. doc perspective?
> > > As long as we define DP (which is what you are suggesting to do) and tell that DP
> > > must give enough information so that the full flow context can be  derived at the
> > > collector, will it not solve this issue?
> > >
> >
> >         Yes it will. I gave example to make sure we were on the
> >         same page. They would not go in the req doc.
> >
> > > >
> > > >         1) send the DP with each flow.
> > > >         2) send the DP with an ID. Then each flow contains
> > > >            a DP-ID field.
> > > >         3) Send the DP for noraml operation and the DP for
> > > >            overload situation. Then only state changes need
> > > >            to be delivered.
> > > >
> > > >         #3 above seems to be what you are talking about.
> > > >
> > > >         However, I think we need to define DP as a term and the set of
> > > >         possible fields and functions first. Add the requirement of mapping
> > > >         a flow to a DP.
> > >
> > > As I see DP is a function of  {1.metering process(s) employed,  2. exporter state,
> > > 3. fields collected}.
> >
> >         I don't see a direct relationship #1 and #2/#3. For example
> >         I could have a DP of source and dest IP but collect (i.e. report)
> >         Src/Dst AS number. Also, the state may change from normal
> >         to overload with no change in DP but rather a dropping of
> >         additional flows.
> 
> It depends on the overload policy.
> * If it is such that say more aggregation (by using less fields) is done in
> the case of an overload (which effecively reduces the # of records
> exported) then there is a relation between 1 & fields exported (may not
> be the fields collected as I mentioned above).
> * If there are fields extracted in the packet path which are not directly
> derived from the packet (like AS #) in the case of an overload, one may
> not collect these fields in the packet path itself.
> * When the exporter state is changed to overload, the metering process
> may be changed from sampling interval X to Y.

	That is why I said "direct" relationship. There may be
	a secondary relationship but one does not drive the
	other.

	Thus, state is not a defining feature of DP.

	Paul

> 
> Thanks
> Ganesh
> 
> >
> >
> >         I think DP stands pretty much on its own.
> 
> > In other words
> >         fields collected and the state are not part of the DP
> >         definition. Those things may influence which DP is used
> >         but they are not part of the DP definition itself.
> >
> >         But I think we are getting a little ahead of the game.
> >         We need to define DP and its fields and functions.
> >
> >         Once we have consensus that we need to define DP and its
> >         fields and functions and we agree we need to map flow
> >         to DP, then we can kick off the discussion.
> >
> > > There is a furthur inter dependency between
> > > * 2&1 (with the exporter state change metering could change),
> > > * 2 & 3 (with the exporter state change fields collected could change),
> > > * 1 & 3 (fields are input tometering functions).
> > >
> > > Am I missing anything?
> > >

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

---

From: Ganesh Sadasivan <[email-masked]>
Date: Tue, 01 Oct 2002 12:00:14 -0700

>         a secondary relationship but one does not drive the

I think I am getting a sense of what you are speaking. Let me re-state it in my own
words and you can correct me if I'm wrong.
- A flow is distinguished by the metering process(es) done on the packet, what
   information is collected out from these operations and any other auxiliary operations
   done using the collected information.
- The metering process(es) itself may change based on the exporter state in which case
   it results in an entirely different flow.

Thanks
Ganesh

-ganesh