Subject: [ipfix-arch] configuration information.

From: Ganesh Sadasivan <[email-masked]>
Date: Mon, 07 Jan 2002 12:09:20 -0800

Hi,
   One of the questions raised during the V9 presenatation if IETF was
   "how a collector would know whether or not the same
   packets or bytes were being reported in more than one flow record
   (e.g. using a different template)." (quoting from the minutes).
   This requires the collector to have configuration information
regading
   the different templates, and the  mode of  selection of packets for
each
   of these templates at each of the observation points.
   This information can be either
   1. Communicated to the collector from the measuring device inband as
a part
   of the export protocol.
   2. The collector gets the required configuration out of band (.i.e
not thru
   the export protocol.

   What are the thoughts of the group on this topic?
   If we are going by 1., should it be a part of the arch- spec? One
think we
   need to keep in mind is that things like , details on method of
packet
   selection could vary widely with implementations.

Thanks
Ganesh

--
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: "Reinaldo Penno"<[email-masked]>
Date: Tue, 8 Jan 2002 07:29:09 -0800

-----Original Message-----
From: Ganesh Sadasivan [mailto:[email-masked]]
Sent: Monday, January 07, 2002 1:37 PM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: [email-masked]'
Subject: Re: [ipfix-arch] configuration information.

Reinaldo, 
I agree with your point that it is non-trivial to derive the complete
relationship 
between the packets collected various templates. My question to the group is
that 
whether IPFIX should spend time on architecting how this detailed config 
information is sent to the collector so that the collector gets this
information inband 
or whether this can be dealt by the collector in an adhoc manner.  
 
Hello Ganesh, 
 
okay, so let me rephrase my comment. Unless someone has some solution in its
sleeve to do this automatically my vote would be not to spend time on this
now since we might come with a solution to pass this info to the collector
but there is no practical use. I do not know how a router/switch/device
would derive the relationship unless it's based on (a lot of) manual
configuration. 
 
In my previous example you would have to query ARIN databases, find the
networks assigned to a specific AS, see if they have ranges in common to the
first template (in specific directions), etc, etc. 
 
thanks,
 
Reinaldo
 
If we go by the former case to what level of details should the collector be

made aware of  about templates, packet selection and their relationships. 

Thanks 
Ganesh 

Reinaldo Penno wrote: 

Hello, 

How a collector would know that a priori? I mean, I can have such general
templates that it would be very difficult to account for duplicate
measurements (even in non real-time). 

If you have very specific templates such as srcIP, destIP, etc, it's not to
hard find records in common. But you can have things like: 

src_AnyIP   Dest_Yahoo.com    Proto_Any   and 
src_AnyIP   Dest_AS3462       Proto_HTTP. 

How do you know a priori that the second rule will have records that are a
subset of the first? Am I missing something? 

thanks, 

Reinaldo 

> -----Original Message----- 
> From: Ganesh Sadasivan [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Monday, January 07, 2002 12:09 PM 
> To: [email-masked] 
> Subject: [ipfix-arch] configuration information. 
> 
> 
> Hi, 
> Help        mailto:[email-masked]
<mailto:[email-masked]>  and say "help" 
> in message body 
> Unsubscribe mailto:[email-masked]
<mailto:[email-masked]>  and say 
> Archive     http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/>

---

From: "Reinaldo Penno"<[email-masked]>
Date: Tue, 15 Jan 2002 14:39:16 -0800

<snip>...<snip>..

> 
> 	Great, then the device reports that all its flows
> 	may overlap. I'm no worse off than not saying anything.
> 	But there are many devices that have relatively simple
> 	counting mechanisms and the extra information will
> 	help down stream applications do some analysis that may 
> 	otherwise not be doable.
> 
> 
> > 

okay. So, can we say that

"in the absence of explicit signalling from the device, the collector MUST
consider that all flows reported can overlap. In the case the device reports
overlapping between certain flows, the collectror SHOULD take this into
consideration, but MUST NOT assume that other flows will not overlap"

is it good enough? Comments?

-Reinaldo