Subject: [IPFIX] IPFIX MIB: read-write choice

From: Benoit Claise <[email-masked]>
Date: Thu, 22 Mar 2007 14:02:45 +0100

Dear all,

During our IPFIX meeting, we discussed IPFIX MIB read-write choice.
My action item was to sent it one last time to the mailing list.
The meeting minute from the IETF 67 meeting were:

    "Juergen: Summary of the discussion. We will have the option for RO
    implementations. Reporting would optionally be RW. Templates will
    probably be RO. Methods: unclear, to be discussed on the list."

The read-write choice that the MIB authors made for the current draft are:
    Transport Session (Group) Table -> Read only, because SCTP/TCP MIB 
variables are not writable
    Observation Domain Table -> Read only
    Template Table -> Read only
    Template Definition Table -> Read only
    Selector Table -> Read only

There is only remaining open issue, discussed during the IPFIX meeting.
Should the template definition table be read-only, or read-write with a 
conformance statement of "read-only"?
Emile Stephan expressed that the read-write is a nice-to-have.
I would like to know whether other people support this read-write.  Or 
shall we leave the template definition table as read-only?

My personal view is that, since that would be the only read-write table, 
I'm not convinced it makes sense.

Regards, Benoit.

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

---

From: Paul Aitken <[email-masked]>
Date: Thu, 22 Mar 2007 14:51:27 +0000

Benoit,

> shall we leave the template definition table as read-only?

The data that's exported from the router dictates what should be in the 
template, not the other way around.

Possibly one could configure "export <this data> in <this template>" but 
from my perspective, it's the wrong approach.

The right approach would be to use a configuration method such as the 
XML scheme which Gerhard discussed.

As an analogy: when we're flying home, the aircraft is an export packet, 
the different classes (first, business, cattle) are data records defined 
by templates (the aircraft layout), and containing various fields (ie, 
the seats).

The airline does not dictate which class we fly in (ie which template we 
use). Instead, we decide for ourselves and tell the airline.

Especially, we do not modify the aircraft layout because more people 
want to fly first class! Generally this requires a new aircraft (export 
packet) with a new layout (new templates).

Besides, if the Template Definition Table is writeable then surely the 
Template Table must also be writeable? So where do you draw the line?

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Paul Aitken <[email-masked]>
Date: Thu, 22 Mar 2007 14:51:27 +0000

Benoit,

---

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Thu, 22 Mar 2007 19:35:55 +0100

Hi Benoit,
 
IPFIX is designed to provide flexibility in terms of choice of the fields to export and in term of aggregation key to be used. So the management interface must reflect this flexibility.
 
Regards
Emile

________________________________

De : Benoit Claise [mailto:[email-masked]] 
Envoyé : jeudi 22 mars 2007 14:03
À : [email-masked]
Objet : [IPFIX] IPFIX MIB: read-write choice
 
Dear all,

	"Juergen: Summary of the discussion. We will have the option for RO implementations. Reporting would optionally be RW. Templates will probably be RO. Methods: unclear, to be discussed on the list." 
    Transport Session (Group) Table -> Read only, because SCTP/TCP MIB variables are not writable 

There is only remaining open issue, discussed during the IPFIX meeting.
Should the template definition table be read-only, or read-write with a conformance statement of "read-only"?
Emile Stephan expressed that the read-write is a nice-to-have. 
I would like to know whether other people support this read-write.  Or shall we leave the template definition table as read-only?

My personal view is that, since that would be the only read-write table, I'm not convinced it makes sense.

Regards, Benoit.

---

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Thu, 22 Mar 2007 19:35:55 +0100

Hi Benoit,

Regards
Emile

 
Dear all,

Regards, Benoit.

---

From: Paul Aitken <[email-masked]>
Date: Thu, 22 Mar 2007 22:01:50 +0000

Emile,

> IPFIX is designed to provide flexibility in terms of choice of the 
> fields to export and in term of aggregation key to be used. So the 
> management interface must reflect this flexibility.

Templates belong to the exporting process. So configuring what's in the 
template only affects the exporting process. It doesn't necessarily 
affect the metering process, so possibly the data is not being observed, 
so it's not available to be exported.

So it's necessary to modify both the monitoring process and the 
exporting process.

In figure 4 of IPFIX-ARCH, I see that data flows from the monitoring 
process to the exporting process, and not the other way.

So it seems to me that the correct approach is to configure the 
monitoring process to monitor the necessary data. Then the exporting 
process realises that this data is being monitored and begins to export it.

So I don't think templates should be writeable; it's the wrong model.

---

From: Paul Aitken <[email-masked]>
Date: Thu, 22 Mar 2007 22:01:50 +0000

Emile,

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 23 Mar 2007 12:53:51 +0100

Paul,

> so it's not available to be exported.

If the Templates belong to the Metering Process or the Exporting Process
was a question that I also had to find an answer for when defining the
configuration data model.

My opinion is that the structure of the Templates, i.e. the set of IEs,
are a parameter of the Metering Process. This becomes very clear in case
of flow export where the IEs (key or non-key) affect the content of the
flow records table (or flow cache).

Therefore, the Template definitions are part of the Metering Process in
the configuration data model. Only, the dynamic assignement of Template
IDs can be seen as a function of the Exporting Process.

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 23 Mar 2007 12:53:51 +0100

Paul,

Regards,
Gerhard

---

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Fri, 30 Mar 2007 12:08:03 +0200

Hi Gerhard,
 
>From a telco perspective the requirement is to be able to configure each components of the IPFIX architecture, including aggregators.
 
These requirements don't depend nor on the language used to specified the datamodel, neither on the protocol used to carry management information.
 
I suggest writing a manageability consideration draft for IPFIX and PSAMP and propose it in the new IPFIX charter.
 
Regards
Emile

-----Message d'origine-----
De : Gerhard Muenz [mailto:[email-masked]] 
Envoyé : vendredi 23 mars 2007 12:54
À : Paul Aitken
Cc : STEPHAN Emile RD-CORE-LAN; [email-masked]
Objet : Re: [IPFIX] IPFIX MIB: manageability consideration

Paul,

 

Regards,
Gerhard

---

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Fri, 30 Mar 2007 12:08:03 +0200

Hi Gerhard,

 
 
Regards
Emile

-----Message d'origine-----
De : Gerhard Muenz [mailto:[email-masked]] 
Envoyé : vendredi 23 mars 2007 12:54
À : Paul Aitken
Cc : STEPHAN Emile RD-CORE-LAN; [email-masked]
Objet : Re: [IPFIX] IPFIX MIB: manageability consideration

Paul,

 

Regards,
Gerhard