Dear all,
Please find comments on draft-ietf-ipfix-mib-04 below.
Currently, we have ipfixTransportSessionTable which does not provide any
information about the role of the given device within the transport
session. We do not know if the device is exporter or collector.
On the other hand, you define "directional" tables for the Templates:
ipfixExportedTemplateTable
ipfixExportedTemplateDefinitionTable
ipfixCollectedTemplateTable
ipfixCollectedTemplateDefinitionTable
Is there any specific reason?
There are two alternatives which require fewer tables:
1) One could add an entry about the role of the device to the
ipfixTransportSessionTable, for example in form of a field with values
"exporter" and "collector". As the Templates are scoped to a given
Transport Session, it is clear which Templates are exported and which
Templates are collected. So we would have only three tables instead of five:
ipfixTransportSessionTable
ipfixTemplateTable
ipfixTemplateDefinitionTable
2) Or, one could split the ipfixTransportSessionTable into:
- ipfixOutgoingTransportSessionTable for Transport Sessions where the
given device is exporter.
- ipfixIncomingTransportSessionTable for Transport Sessions where the
given device is collector.
Again, we only need two tables for the Templates:
ipfixTemplateTable
ipfixTemplateDefinitionTable
Reducing the number of tables is certainly not a design goal for MIBs.
However, I think that it is more logical to have the information of the
device role (exporter and collector) together with the data about the
Transport Session.
> 5.3. The Template Tables
>
> There are two Template tables, the Exported Template
> (ipfixExportedTemplateTable) table and the Collected Template table
> (ipfixCollectedTemplateTable). Those Template tables list all
> Templates (including Option Templates) that are sent (by an Exporter)
> or received (by a Collector). The (Option) Templates are unique per
> Transport Session and Observation Domain, thus the table is indexed
> by the Transport Session Index (ipfixTransportSessionIndex) and the
> Observation Domain Id (ipfixExportedObservationDomainId or
> ipfixCollectedObservationDomainId). It contains the Set Id and an
I propose to list the indices in a clearer way one below the other:
The (Option) Templates are unique per
Transport Session and Observation Domain, thus the table is indexed
by the following indices:
- Transport Session Index (ipfixTransportSessionIndex)
- Observation Domain Id (ipfixExportedObservationDomainId or
ipfixCollectedObservationDomainId).
With two indices, explaining them in the text may still be ok. But you
have much longer lists of indices for the other Tables.
> Access Time denoting the time when the (Option) Template was last
> sent or received.
>
> To resume the above example the Exporter may want to export the a
remove "the" or "a"
> Template and an Option Template for each Transport Session defined
> above. This leads to the following Template Table defining Template
> and Option Template:
>
> ipfixExportedTemplateTable (3)
> |
> +- ipfixExportedTemplateEntry (1)
> |
> +- index (5)
> | +- index (3)
> | + index (257)
It is difficult to deduce the meaning of the indices. Maybe add in
brackets which index refers to what:
+- index (5) (ipfixTransportSessionIndex)
| +- index (3) (ipfixExportedObservationDomainId)
| + index (257) (ipfixExportedTemplateId)
> | | +- ipfixExportedObservationDomainId (1) = 3
> | | +- ipfixExportedTemplateId (2) = 257
> | | +- ipfixExportedTemplateSetId (3) = 2
> | | +- ipfixExportedTemplateAccessTime (4)
> | | = 2008-7-1,12:49:11.2,+2:0
> | |
> | + index (264)
> | +- ipfixExportedObservationDomainId (1) = 3
> | +- ipfixExportedTemplateId (2) = 264
> | +- ipfixExportedTemplateSetId (3) = 3
> | +- ipfixExportedTemplateAccessTime (4)
> . = 2008-7-1,12:47:04.8,+2:0
> .
> .
> .
> +- index (11)
> +- index (3)
> + index (273)
> | +- ipfixExportedObservationDomainId (1) = 3
> | +- ipfixExportedTemplateId (2) = 273
> | +- ipfixExportedTemplateSetId (3) = 2
> | +- ipfixExportedTemplateAccessTime (4)
> | = 2008-7-1,12:49:11.2,+2:0
> |
> + index (289)
> +- ipfixExportedObservationDomainId (1) = 3
> +- ipfixExportedTemplateId (2) = 289
> +- ipfixExportedTemplateSetId (3) = 3
> +- ipfixExportedTemplateAccessTime (4)
> = 2008-7-1,12:47:04.8,+2:0
>
> We assume that the Collector with index 5 in the Transport Session
> table of the Exporter has stored the connection to the Exporter with
> the Transport Session index of 17 then its Template table would look
> as follows:
The sentence is confusing. The Transport Session tables does not contain
any entry called Collector, only ipfixTransportSessionDestinationAddress
and ipfixTransportSessionDestinationPort.
Maybe:
We assume that the Transport Session that is stored with index 5 in the
Transport Session table of the Exporter is stored with index 17 in the
Transport Session table of the (corresponding) Collector. Then, the
Template table would look as follows:
> 5.4. The Template Definition Tables
>
> As with the Template tables there are two Template Definition tables,
> the Exported Template Definition table
> (ipfixExportedTemplateDefinitionTable) and the Collected Template
> Definition table (ipfixCollectedTemplateDefinitionTable). Those
> tables list all the Information Elements contained in a Template or
> Option Template. Therefore it has the same indexes as the
> corresponding Template table plus the Template Id. Its own index
> denotes the order of the Information Element inside the Template if
> necessary. Besides the Information Element Id and the length of the
> encoded value the table contains flags for each Information Element.
> The flags indicate if the Information Element is used for scoping or
> as a Flow key.
What about enterprise-specific IEs? Don't we need an enterprise number
entry?
> 5.5. The Export Table
>
> On Exporters, the Export table (ipfixExportTable) can be used to
> support features like failover, load-balancing, duplicate export to
> several Collectors etc. The table has 5 indexes that link an entry
> with the Metering Process table (ipfixMeteringProcessCacheId, see
> below), the Exported Template table (ipfixExportedObservationDomainId
> and ipfixExportedTemplateId) and the Transport Session table
> (ipfixTransportSessionIndex). Those entries with the same
Is there a reason for not ordering the indexes as they appear in the MIB?
> ipfixExportIndex, the same ipfixMeteringProcessCacheId and the same
> ipfixExportedObservationDomainId define a Transport Session group.
> This also The member type for each group member describes its
remove "This also"
> functionality.
Why is a Transport Session group restricted to the output of a single cache?
> If the Exporter does not use Transport Session grouping then each
> ipfixExportIndex contains a single ipfixMeteringProcessCacheId and
ipfixTransportSessionIndex?
> thus a singe Transport Session and this session MUST have the member
single
> type primary(1).
> To continue the example we assume that the Exporter uses the 2
two
> connections shown in the examples above as the primary export for a
> session protected by a secondary backup connection. The Exporter
> then has the following entries in the ipfixExportTable:
>
> ipfixExportTable (3)
> |
> +- ipfixExportEntry (1)
> |
> +- index (7)
> | +- index (9)
> | +- index (3)
> | +- index (257)
> | | +- index (5)
> | | +- ipfixExportIndex (1) = 7
> | | +- ipfixExportMemberType (2) = 1 (primary)
> | |
> | +- index (273)
> | +- index (11)
> | +- ipfixExportIndex (1) = 7
> | +- ipfixExportMemberType (2) = 2 (secondary)
> |
> +- index (8)
> +- index (9)
> +- index (3)
> +- index (264)
> | +- index (5)
> | +- ipfixExportIndex (1) = 8
> | +- ipfixExportMemberType (2) = 2 (secondary)
> +- index (289)
> +- index (11)
> +- ipfixExportIndex (1) = 7
8?
> +- ipfixExportMemberType (2) = 1 (primary)
Can you explain this example?
There are two Metering Processes? And the output is sent to different
primary collectors? And in case of a failure, each collector serves as
backup for the other?
> 5.6. The Metering Process Table
>
> The Metering Process as defined in [RFC5101] consists of a set of
> function. Maintaining the Flow Records is one of them. This
> function is responsible for passing the Flow Records to the Exporting
> Process but also for detecting Flow expiration. The Flow Records
"but also" => "and also"
> that are maintained by the Metering Process can be grouped by the
> Observation Points they are observed. The instance that maintains
> such a group of Flow Records is a kind of cache. For this reason the
> Metering Process table (ipfixMeteringProcessTable) is grouped by
> cache IDs (ipfixMeteringProcessCacheId). Each cache can be
> maintained by a separate instance of the Metering Process which is
> represented by the Metering Process ID (ipfixMeteringProcessId). To
> specify the Observation Point(s) where the Flow Records are gathered
> the ipfixObservationPointGroupReference may contain the an
"the" or "an"?
> ipfixObservationPointGroupId from the Observation Point table
> (ipfixObservationPointTable) described in the next section. If an
> Observation Point cannot be given the
What do you mean by "cannot be given"?
> ipfixObservationPointGroupReference MUST be zero(0). The timeouts
> (ipfixMeteringProcessCacheActiveTimeout and
> ipfixMeteringProcessCacheInactiveTimeout) specify when Flow Records
> are passed to the Exporting Process.
>
> ipfixMeteringProcessTable(8)
> |
> +- ipfixMeteringProcessEntry(1)
> |
> +- index(9)
> +- ipfixMeteringProcessCacheId(1) = 9
> +- ipfixMeteringProcessId(2) = 287
> +- ipfixObservationPointGroupReference(3) = 17
> +- ipfixMeteringProcessCacheActiveTimeout(4) = 100
> +- ipfixMeteringProcessCacheInactiveTimeout(5) = 100
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: muenz at informatik.uni-tuebingen.de
WWW: http://net.informatik.uni-tuebingen.de/~muenz
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ IPFIX mailing list IPFIX at ietf.org https://www.ietf.org/mailman/listinfo/ipfix