Subject: [IPFIX] Issue on IPFIX MIB

From: "Thomas Dietz" <[email-masked]>
Date: Mon, 25 Feb 2008 09:55:07 +0100

Dear all,

Benoit raised an issue with the IPFIX MIB in his mail to the list
(http://www.ietf.org/mail-archive/web/ipfix/current/msg04216.html). This
issues comes out of the real world implementation of the IPFIX protocol. The
problem is that timeout values that time out flows are located at the
template in the MIB. Now in the real world these timeouts are located at
caches. To maFrom [email-masked]  Mon Feb 25 00:55:59 2008
Content-class: urn:content-classes:message
Date: Mon, 25 Feb 2008 09:55:07 +0100
From: "Thomas Dietz" <[email-masked]>
To: "IETF IPFIX Working Group" <[email-masked]>
Cc: Juergen Quittek <[email-masked]>
Subject: [IPFIX] Issue on IPFIX MIB
Sender: [email-masked]

This is a multipart message in MIME format.
Dear all,

Benoit raised an issue with the IPFIX MIB in his mail to the list
(http://www.ietf.org/mail-archive/web/ipfix/current/msg04216.html). This
issues comes out of the real world implementation of the IPFIX protocol. The
problem is that timeout values that time out flows are located at the
template in the MIB. Now in the real world these timeouts are located at
caches. To make things worse caches cannot be 1:1 mapped to templates.
Several caches can export their data with the same template.

As a consequence we need to change the MIB. Since we don't have the term
cache in our drafts one possibility would be to just eliminate the timeouts
and make their use implementation dependant and not visible in the MIB.

The second possibility would be to map the caches (and especially their
timeouts) to the Metering Process. So we would get another table with e.g. a
Metering Process ID and the timeouts. As a consequence we need to re-link
all the tables (change their indexes) in the MIB to integrate the new
Metering Process table.

I will try to come up with such a new MIB structure asap, send it to the
list and gather your comments.

Hope to find a solution soon,

Best Regards,

Thomas

-- 
Thomas Dietz                 E-mail: [email-masked]
NEC Europe Ltd.              Phone:  +49 6221 4342-128
NEC Laboratories Europe      Fax:    +49 6221 4342-155
Network Research Division
Kurfuersten-Anlage 36
69115 Heidelberg, Germany    http://www.nw.neclab.eu

NEC Europe Limited           Registered in England 2832014
Registered Office: NEC House, 1 Victoria Road, London W3 6BL

_______________________________________________
IPFIX mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Mon, 25 Feb 2008 14:02:06 +0000

Thomas,

> (http://www.ietf.org/mail-archive/web/ipfix/current/msg04216.html). 
> This issues comes out of the real world implementation of the IPFIX 
> protocol. The problem is that timeout values that time out flows are 
> located at the template in the MIB. Now in the real world these 
> timeouts are located at caches.

That makes a lot of sense, since these timeouts pertain to flows, and
caches are collections of flows. Whereas templates are produced by the
exporting process (IPFIX-ARCH, figure 6) and are therefore a step too
far along in the IPFIX process. In short, templates can't control the
timing of data export!

> To make things worse caches cannot be 1:1 mapped to templates. 

The contents of a single cache could be exported using multiple
templates. eg, templates could be created based on which fields were
available. ie, if a value was not observed for a particular field then a
new template would be created which doesn't include that field.

> As a consequence we need to change the MIB. Since we don't have the 
> term cache in our drafts one possibility would be to just eliminate 
> the timeouts and make their use implementation dependant and not 
> visible in the MIB.

Looking at IPFIX-ARCH figure 4, surely these timers control the transfer
of data from the metering process to the exporting process? So in a
sense they're a missing piece of the IPFIX picture, and eliminating them
doesn't make sense.

> The second possibility would be to map the caches (and especially 
> their timeouts) to the Metering Process. So we would get another 
> table with e.g. a Metering Process ID and the timeouts.

You should allow the possibility of multiple caches per metering
process, each with their own properties. eg, hardware and software
caches that are configured independently.

The difference between one metering process with N caches, and N
metering processes each with their own cache, is that in the former case
a packet is processed only once and appears in just one of the caches,
whereas in the latter case the packet may be processed N times and
appear once in each cache.

Further, changing the parameters of a metering process affects the N
caches which it populates, whereas each metering process is independent,
so changing the configuration of one doesn't normally change the
configuration of any other. The only exception is when a global timeout
is enforced across all caches.

Cheers,
P.

> As a consequence we need to re-link all the tables (change their 
> indexes) in the MIB to integrate the new Metering Process table.
> 
> I will try to come up with such a new MIB structure asap, send it to 
> the list and gather your comments.
> 

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.
_______________________________________________
IPFIX mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Mon, 25 Feb 2008 14:02:06 +0000

Thomas,

Cheers,
P.