[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




Dear all,

Thomas Dietz wrote:
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

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: muenz at net.in.tum.de    WWW: http://www.net.in.tum.de/~muenz


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature