Subject: [IPFIX] review: draft-ietf-ipfix-mib-03

From: Paul Aitken <[email-masked]>
Date: Wed, 12 Mar 2008 16:00:48 +0000

ThomaFrom [email-masked]  Wed Mar 12 09:03:54 2008
Date: Wed, 12 Mar 2008 16:00:48 +0000
From: Paul Aitken <[email-masked]>
To: Thomas Dietz <[email-masked]>,
	kobayashi atsushi <[email-masked]>, Benoit Claise <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [IPFIX] review: draft-ietf-ipfix-mib-03
Sender: [email-masked]

Thomas, Atsushi-san, Benoit,

Here with a quick review of draft-ietf-ipfix-mib-03.

Mostly just editorial stuff, except for a question on the 
ipfixTransportSessionGroupTable.

Cheers,
P.

5.1. The Transport Session Table

>    For SCTP the table contains the SCTP Assoc Id

I'd prefer to say "SCTP association ID", else use "sctpAssocId" per RFC 
3873.

5.1.1. The Transport Session Group Table

>    For failover a Transport Session group can contain one Transport
>    Session with member type "primary" and several Transport Sessions
>    with type "secondary".  Entries with other member types are not
>    allowed for that group.

Unfortunately this doesn't allow for a very flexible hierarchy.

>    The values in brackets are the OID numbers.  The Collector would then
>    have the same entry except that the index would be different (e.g. 17).
                                         may ---^^^^^

>    We further asume that the Exporter uses the above connection as the
>    primary export for a session protected by a secondary backup
>    connection with an ipfixTransportSessionIndex of 28.  Both, Exporter
>    and Collector, also need to have a Transport Session Group Table.
>    For the export this may look like the following table:

-> "Both the Exporter and Collector need to have ..."

>    Since the Collector does not know which Transport Sessions belong
>    together it has one Transport Session Group Table entry per Transport
>    Session.  So the entry for the given example is the following:

Why have the ipfixTransportSessionGroupTable on the collector at all?

5.2. The Observation Domain Table

>    The Observation Domain Table (ipfixObservationDomainTable) contains a
>    reference to the ENTITY MIB [RFC4133].  The objects in the ENTITY MIB
>    denote the Observation Point associated with the given Observation
>    Domain Id.  In addition a direction can be given to render more
>    specific which flow to monitor.

"specifically".

>    Since a Collector could receive the
>    same Observation Domain Id in different sessions (thus from different
>    Exporters) the table takes the Transport Session index as first
>    index.  The Transport Session index would be typically zero (0) at an
>    Exporter because the Observation Domain Id is usually unique per
>    Device and thus need not to be scoped by the Transport Session.

Who can say what is usual? eg the above may not hold for an intermediate 
node (eg, an aggregator).

Rather, consider:

      The Transport Session index may be zero (0) when the Observation
      Domain Id is unique per Device and does not need to be scoped by
      the Transport Session.

5.3. The Template Table

>    In addition it contains an inactive timeout
>    to terminate Flows that are inactive for a certain amount of time and
>    an active timeout to expire Flows that are still active to get
>    intermediate Flow Records for these long-living Flows.

Surely these timeouts are properties of the cache in which these flows 
are stored, and really nothing to do with the templates?

5.4. The Template Definition Table

>    This leads to the following Template Table defining Template and
>    Option Template:
> 
>     ipfixTemplateTable (5)
>     |
>     +- ipfixTemplateEntry (1)
>        |
>        +- index (11)
>           |
>           +- index (3)
>              |
>              + index (257)
>              | +- ipfixTemplateId (1) = 257
>              | +- ipfixTemplateSetId (2) = 2
>              | +- ipfixTemplateAccessTime (3) = 2007-7-9,12:49:11.2,+2:0
>              | +- ipfixTemplateActiveTimeout (4) = 0
>              | +- ipfixTemplateInactiveTimeout (5) = 500
>              |
>              + index (264)
>                +- ipfixTemplateId (1) = 264
>                +- ipfixTemplateSetId (2) = 3
>                +- ipfixTemplateAccessTime (3) = 2007-7-9,12:47:04.8,+2:0
>                +- ipfixTemplateActiveTimeout (4) = 0
>                +- ipfixTemplateInactiveTimeout (5) = 0

Template 264 isn't mentioned elsewhere, so could just be removed from 
here fors, Atsushi-san, Benoit,

Here with a quick review of draft-ietf-ipfix-mib-03.

Mostly just editorial stuff, except for a question on the 
ipfixTransportSessionGroupTable.

Cheers,
P.

5.1. The Transport Session Table

>    For SCTP the table contains the SCTP Assoc Id

I'd prefer to say "SCTP association ID", else use "sctpAssocId" per RFC 
3873.

5.1.1. The Transport Session Group Table

>    For failover a Transport Session group can contain one Transport
>    Session with member type "primary" and several Transport Sessions
>    with type "secondary".  Entries with other member types are not
>    allowed for that group.

Unfortunately this doesn't allow for a very flexible hierarchy.

>    The values in brackets are the OID numbers.  The Collector would then
>    have the same entry except that the index would be different (e.g. 17).
                                         may ---^^^^^

>    We further asume that the Exporter uses the above connection as the
>    primary export for a session protected by a secondary backup
>    connection with an ipfixTransportSessionIndex of 28.  Both, Exporter
>    and Collector, also need to have a Transport Session Group Table.
>    For the export this may look like the following table:

-> "Both the Exporter and Collector need to have ..."

>    Since the Collector does not know which Transport Sessions belong
>    together it has one Transport Session Group Table entry per Transport
>    Session.  So the entry for the given example is the following:

Why have the ipfixTransportSessionGroupTable on the collector at all?

5.2. The Observation Domain Table

>    The Observation Domain Table (ipfixObservationDomainTable) contains a
>    reference to the ENTITY MIB [RFC4133].  The objects in the ENTITY MIB
>    denote the Observation Point associated with the given Observation
>    Domain Id.  In addition a direction can be given to render more
>    specific which flow to monitor.

"specifically".

>    Since a Collector could receive the
>    same Observation Domain Id in different sessions (thus from different
>    Exporters) the table takes the Transport Session index as first
>    index.  The Transport Session index would be typically zero (0) at an
>    Exporter because the Observation Domain Id is usually unique per
>    Device and thus need not to be scoped by the Transport Session.

Who can say what is usual? eg the above may not hold for an intermediate 
node (eg, an aggregator).

Rather, consider:

      The Transport Session index may be zero (0) when the Observation
      Domain Id is unique per Device and does not need to be scoped by
      the Transport Session.

5.3. The Template Table

>    In addition it contains an inactive timeout
>    to terminate Flows that are inactive for a certain amount of time and
>    an active timeout to expire Flows that are still active to get
>    intermediate Flow Records for these long-living Flows.

Surely these timeouts are properties of the cache in which these flows 
are stored, and really nothing to do with the templates?

5.4. The Template Definition Table

>    This leads to the following Template Table defining Template and
>    Option Template:
> 
>     ipfixTemplateTable (5)
>     |
>     +- ipfixTemplateEntry (1)
>        |
>        +- index (11)
>           |
>           +- index (3)
>              |
>              + index (257)
>              | +- ipfixTemplateId (1) = 257
>              | +- ipfixTemplateSetId (2) = 2
>              | +- ipfixTemplateAccessTime (3) = 2007-7-9,12:49:11.2,+2:0
>              | +- ipfixTemplateActiveTimeout (4) = 0
>              | +- ipfixTemplateInactiveTimeout (5) = 500
>              |
>              + index (264)
>                +- ipfixTemplateId (1) = 264
>                +- ipfixTemplateSetId (2) = 3
>                +- ipfixTemplateAccessTime (3) = 2007-7-9,12:47:04.8,+2:0
>                +- ipfixTemplateActiveTimeout (4) = 0
>                +- ipfixTemplateInactiveTimeout (5) = 0

Template 264 isn't mentioned elsewhere, so could just be removed from 
here for clarity.

>   The Template Definition Table for the Template may look like follows:
> 
>    ipfixTemplateDefinitionTable (6)
>    |
>    +- ipfixTemplateDefinitionEntry (1)
>       |
>       +- index (11)
>          |
>          +- index (3)
>             |
>             + index (257)
>               |
>               +- index (1)
>               |  +- ipfixTemplateDefinitionIndex (1) = 1
>               |  +- ipfixTemplateDefinitionIeId (2) = 158
>               |  |                          (flowStartDeltaMicroseconds)
>               |  +- ipfixTemplateDefinitionIeLength (3) = 4
>               |  +- ipfixTemplateDefinitionFlags (4) = 0
>               |
>               +- index (2)
>               |  +- ipfixTemplateDefinitionIndex (1) = 2
>               |  +- ipfixTemplateDefinitionIeId (2) = 159
>               |  |                          (flowStartDeltaMicroseconds)

That should be flowEndDeltaMicroseconds.

5.6. The Selector Functions

>    The subtree ipfixSelectorFunctions is a placeholder where all
>    standard filtering and sampling functions should be located (if any)
>    and is mainly built for extensibility in future versions.  It
>    currently contains the Select All functions (ipfixFuncSelectAll).
                                        ^^^^^^^^^
"function" (ie, singular).

5.6.1. Textual Convention IpfixFunctionAvailabilty

>    In conjunction with the Selector Functions the textual convention
>    IpfixFunctionAvailabilty is defined in the MIB.  It MUST be used
>    within all Selector Functions to indicate if a standard function is
>    currently available at the Device or not.  The previously mentioned
>    Select All function is always available.
                          ^^
"MUST always be available".

5.7. The Statistical Tables

>    The remaining tables are all for statistical evaluation and all of
>    them are optional.  Those table gather statistical values for a
>    corresponding table of those described above.

"These tables gather statistical values for the corresponding tables 
described above."

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

 clarity.

>   The Template Definition Table for the Template may look like follows:
> 
>    ipfixTemplateDefinitionTable (6)
>    |
>    +- ipfixTemplateDefinitionEntry (1)
>       |
>       +- index (11)
>          |
>          +- index (3)
>             |
>             + index (257)
>               |
>               +- index (1)
>               |  +- ipfixTemplateDefinitionIndex (1) = 1
>               |  +- ipfixTemplateDefinitionIeId (2) = 158
>               |  |                          (flowStartDeltaMicroseconds)
>               |  +- ipfixTemplateDefinitionIeLength (3) = 4
>               |  +- ipfixTemplateDefinitionFlags (4) = 0
>               |
>               +- index (2)
>               |  +- ipfixTemplateDefinitionIndex (1) = 2
>               |  +- ipfixTemplateDefinitionIeId (2) = 159
>               |  |                          (flowStartDeltaMicroseconds)

That should be flowEndDeltaMicroseconds.

5.6. The Selector Functions

>    The subtree ipfixSelectorFunctions is a placeholder where all
>    standard filtering and sampling functions should be located (if any)
>    and is mainly built for extensibility in future versions.  It
>    currently contains the Select All functions (ipfixFuncSelectAll).
                                        ^^^^^^^^^
"function" (ie, singular).

5.6.1. Textual Convention IpfixFunctionAvailabilty

>    In conjunction with the Selector Functions the textual convention
>    IpfixFunctionAvailabilty is defined in the MIB.  It MUST be used
>    within all Selector Functions to indicate if a standard function is
>    currently available at the Device or not.  The previously mentioned
>    Select All function is always available.
                          ^^
"MUST always be available".

5.7. The Statistical Tables

>    The remaining tables are all for statistical evaluation and all of
>    them are optional.  Those table gather statistical values for a
>    corresponding table of those described above.

"These tables gather statistical values for the corresponding tables 
described above."

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