Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mib-08.txt

From: "Thomas Dietz" <[email-masked]>
Date: Mon, 2 Nov 2009 16:53:21 +0100

Dear all, 

as you may have seen a new version of draft-ietf-ipfix-mib was published.
Changes in this version are:

- removed global ipfixExportVersion
- added version information per Transport Session
- removed ipfixTemplateObservationDomainId and ipfixTemplateId as index in
the ipfixExportTable
- minor editorial fixes

One point that recently was raised by Gerhard is still open:

- add Observation Domain Id into the Observation Point table if possible

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Montag, 26. Oktober 2009 17:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mib-08.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IP Flow Information Export Working
> Group of the IETF.
> 
> 
> 	Title           : Definitions of Managed Objects for IP Flow
> Information Export
> 	Author(s)       : T. Dietz, et al.
> 	Filename        : draft-ietf-ipfix-mib-08.txt
> 	Pages           : 67
> 	Date            : 2009-10-26
> 
> This document defines managed objects for IP Flow Information Export
> (IPFIX).  These objects provide information for monitoring IPFIX
> Exporters and IPFIX Collectors including the basic configuration
> information.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-08.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 06 Nov 2009 17:51:07 +0100

Dear all,

> - add Observation Domain Id into the Observation Point table if possible

Let me explain this issue a bit more.

We have the following Observation Point table:

ipfixObservationPointTable(6)
|
+-ipfixObservationPointEntry(1) 
[ipfixObservationPointGroupId,ipfixObservationPointIndex]
   |
   + Unsigned32          ipfixObservationPointGroupId(1)
   + Unsigned32          ipfixObservationPointIndex(2)
   + PhysicalIndexOrZero ipfixObservationPointPhysicalEntity(3)
   + Enumeration         ipfixObservationPointPhysicalEntityDirection(4)

 From this table, it is not possible to retrieve the Observation Domain 
ID of an Observation Point.

If an IPFIX Exporter establishes a Transport Session to a Collector, 
there is an entry in the Transport Session table.  Associated to this 
entry, we have the Templates in the Template table.  There, we can 
finally find the Observation Domain ID.

This procedure is quite complicated and does not work if no Transport 
Sessions are established.

Possible solutions:

1) We do not care because nobody is interested in the mapping between 
Observation Points and Observation Domains.

2) We add ipfixObservationPointObservationDomainId to the Observation 
Point table (as a normal parameter, not as an index).

Personally, I prefer solution 2.

There is a related issue regarding the relationship between Observation 
Domain and Metering Process.

RFC5101 says:

    Observation Domain

       An Observation Domain is the largest set of Observation Points for
       which Flow information can be aggregated by a Metering Process.

Some people interpreted this definition as if only packets of a single 
Observation Domain may enter a Metering Process/Cache.  In this case, it 
follows that Observations Points sharing the same 
ipfixObservationPointGroupId must have identical Observation Domain ID 
values.  This fact could be added in the description clause of 
ipfixObservationPointGroupId:
   "All Observation Points belonging to the same group must belong to the
    same Observation Domain."

However, I understand the definition differently.  IMO, it does not say 
that packets from different Observation Domains must not enter the same 
Metering Process.  It just says that a single Flow Record only accounts 
packets of a single Observation Domain.  To achieve this, it is 
sufficient that the Metering Process/Cache treats the Observation Domain 
ID as an additional Flow Key.

It would be nice to get to an agreement regarding the understanding of 
the relationship between Observation Domain and Metering Process.

The outcome does not only concern the IPFIX-MIB, but also the 
configuration data model.

Best regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Technische Universität München - Department of Informatics
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

---

From: Gerhard Muenz <[email-masked]>
Date: Tue, 10 Nov 2009 16:07:46 +0100

Hi again,

Discussing this issue with Benoit, I would like to comment my own 
statements inline:

> ID of an Observation Point.

To understand why this might be interesting, consider the following use 
case:

You receive an IPFIX message with an Observation Domain ID value in the 
message header. Now, you want to query the IPFIX-MIB which are the 
Observation Points.

> Sessions are established.

Stating that there exists a complicated solution was a mistake!
In fact, it is not possible to get the information in the general case.

Explanation:

 From ipfixTransportSessionTable, we can get the 
ipfixObservationDomainId per ipfixTemplateEntry used in a given 
Transport Session (using ipfixTransportSessionIndex as common index).

On the other hand, we can link the ipfixTransportSessionEntry to one or 
multiple ipfixMeteringProcessCacheIds with help of the ipfixExportTable. 
Only if the Transport Session is linked to a single Metering Process, we 
can go further and find the ipfixMeteringProcessObservationPointGroupRef 
in the ipfixMeteringProcessTable.

If ipfixExportTable relates one ipfixTransportSessionEntry to multiple 
ipfixMeteringProcessCacheIds, we may find several 
ipfixMeteringProcessObservationPointGroupRef values pointing to multiple 
ipfixObservationPointGroupEntries. Then, we do not know how to do a 
one-to-one-mapping between multiple Observation Domain IDs and multiple 
Observation Point groups.

So, in summary, the IPFIX MIB is useless for the use case mentioned 
above. Adding ipfixObservationPointObservationDomainId solves this problem.

Regards,
Gerhard

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