Subject: RE: [ipfix-arch] configuration information.

From: "Reinaldo Penno"<[email-masked]>
Date: Mon, 7 Jan 2002 12:51:46 -0800

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]]
> Sent: Monday, January 07, 2002 12:09 PM
> To: [email-masked]
> Subject: [ipfix-arch] configuration information.
> 
> 
> 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: Ganesh Sadasivan <[email-masked]>
Date: Mon, 07 Jan 2002 13:36:54 -0800

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.
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:
>
> 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
>
>

---

From: [email-masked]
Date: Tue, 08 Jan 2002 11:19:27 -0500

> > src_AnyIP   Dest_AS3462       Proto_HTTP.

	I assume here you mean that there are 2 counters and
	2 "flows" reported. One has (to use cisco terms) a template
	of "dest-ip, byes, packets" and the other "dest-AS, proto,
	byes, packets". 

	If the device uses a multi-match method then the device 
	"knows" that a packet may be added to both buckets. It 
	should tell the collector that these templates overlap. 
	If on the other hand the device uses a first match method 
	then the counts do not overlap. When the application is
	processing records reported via these templates it "knows"
	whether adding the byes/packets from these templates 
	makes sense.

--
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/