Subject: Re: [MIB-DOCTORS] [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt (ipfixExportEntry)

From: Atsushi Kobayashi <[email-masked]>
Date: Fri, 08 May 2009 14:46:10 +0900

Dear Thomas, Benoit, Gerhard and all,

Sorry for late reply.

I have concerns about the modification for the following comment. 
The MIB draft -06 was modified for the ipfixExportIndex to be located at
the end of indexes. But, I wonder the order of these indexes is
difficult to represent the Transport Session group. 

I prefer to keep the order of 3 tuple indexes
(ipfixMeteringProcessCacheId, ipfixTemplateObservationDomainId,
ipfixExportGroupIndex) in order to understand easily the result of
snmpwalk, even if the MIB structure changes a little bit.

> > T16. ipfixExportEntry leads to a warning in the smicng compilation
> > 
> > W: f(ipfix.mi2), (676,12) Row "ipfixExportEntry" does not have a
> > consistent indexing scheme - index items from current table must come
> > after index items from other tables
> > 
> 
> Since I have only libsmi (which does not catch this) I did not realize it.
> Fixed.

I propose to add ExportGroupTable as follows. What do you think about it?

   --------------------------------------------------------------------
   -- 1.1.5: Export Group Table
   --------------------------------------------------------------------
   ipfixExportGroupTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF IpfixExportGroupEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists all export groups.
           On Collectors this table is not needed."
       ::= { ipfixMainObjects 5 }

   ipfixExportGroupEntry OBJECT-TYPE
       SYNTAX      IpfixExportGroupEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the ipfixExportGroupTable"
       INDEX       {
           ipfixMeteringProcessCacheId,
           ipfixTemplateObservationDomainId,  
           ipfixExportGroupIndex
       }
       ::= { ipfixExportGroupTable 1 }

   IpfixExportGroupEntry ::=
       SEQUENCE {
          ipfixExportGroupIndex      Unsigned32,
          ipfixExportGroupType       INTEGER
       }

   ipfixExportGroupIndex OBJECT-TYPE
       SYNTAX      Unsigned32 (1..4294967295)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Locally arbitrary, but unique identifier of an entry in
           the ipfixExportGroupTable. The value is expected
           to remain constant from a re-initialization of the entity's
           network management agent to the next re-initialization.

           A common ipfixExportGroupIndex between two entries from ipfix 
           Export table expresses that there is a relationship between the
           Transport Sessions in ipfixTransportSessionIndex. The type
           of Trasport Session group is expressed by the value of
           ipfixExportMemberType."
       ::= { ipfixExportGroupEntry 1 }

   ipfixExportGroupType OBJECT-TYPE
       SYNTAX      INTEGER {
                       unknown(0),
                       failover(1),
                       duplicate(2),
                       loadBalancing(3)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The type of a Transport Session group 
           (identified by the value of ipfixExportGroupIndex,
           ipfixObservationDomainId and ipfixMeteringProcessCacheId).
           The following values are valid:

           unknown(0)
               This value MUST be used if the status of the group
               membership cannot be detected by the equipment. This
               value should be avoided as far as possible.

           failover(1)
               This value is used for a group member that is used as
               the primary or secondary target of an Exporter. 
               This value MUST also be specified if the Exporter does
               not support Transport Session grouping. In this case the
               group contains only one Transport Session.

           duplicate(2)
               This value is used for a group member that is used for
               duplicate exporting i.e., all group members identified
               by the ipfixExportIndex are exporting the same Records
               in parallel. This implies that all group members MUST
               have the the same membertype duplicate(3).

           loadBalancing(3)
               This value is used for a group member that is used as
               as one target for load-balancing. This means that a
               Record is sent to one of the group members in this
               group identified by ipfixExportIndex.
               This implies that all group members MUST have the same
               membertype load-balancing(4)."
       ::= { ipfixExportGroupEntry 2 }

   --------------------------------------------------------------------
   -- 1.1.6: Export Table
   --------------------------------------------------------------------
   ipfixExportTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF IpfixExportEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists all exports of an IPFIX device.

           On Exporters this table contains all exports grouped by
           Transport Session, Observation Domain Id, Template Id and
           Metering Process represented by the
           ipfixMeteringProcessCacheId. Thanks to the ipfixExportGroupIndex
           the exports can group one or more Transport Sessions to
           achieve a special functionality like failover management,
           load-balancing etc. The entries with the same
           ipfixExportGroupIndex, the same ipfixObservationDomainId
           and the same ipfixMeteringProcessCacheId define a Transport
           Session group. If the Exporter does not use Transport
           Session grouping then each ipfixGroupExportIndex contains a
           single ipfixMeteringProcessCacheId and thus a singe
           Transport Session and this session MUST have the member
           type primary(1). Transport Sessions referenced in this
           table MUST have the ipfixTransportSessionMode exporting(1).

           On Collectors this table is not needed."
       ::= { ipfixMainObjects 6 }

   ipfixExportEntry OBJECT-TYPE
       SYNTAX      IpfixExportEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the ipfixExportTable"
       INDEX       {
           ipfixMeteringProcessCacheId,
           ipfixTemplateObservationDomainId,
           ipfixExportGroupIndex,
           ipfixTransportSessionIndex,
           ipfixTemplateId
       }
       ::= { ipfixExportTable 1 }

   IpfixExportEntry ::=
       SEQUENCE {
          ipfixExportMemberType INTEGER
       }

   ipfixExportMemberType OBJECT-TYPE
       SYNTAX      INTEGER {
                       unknown(0),
                       primary(1),
                       secondary(2)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The type of a member Transport Session in a Transport
           Session group (identified by the value of ipfixExportIndex,
           ipfixObservationDomainId and ipfixMeteringProcessCacheId).
           The following values are valid:

           unknown(0)
               If the Transport Session group uses duplicate or load 
               balancing, the type of a member Transport Session MUST 
               have the member type unknown(0).

           primary(1)
               This value is used for a group member that is used as
               the primary target of an Exporter. Other group members
               (with the same ipfixExportIndex and
               ipfixMeteringProcessCacheId) MUST NOT have the value
               primary(1) but MUST have the value secondary(2).

           secondary(2)
               This value is used for a group member that is used as a
               secondary target of an Exporter. The Exporter will use
               one of the targets specified as secondary(2) within the
               same Transport Session group when the primary target is
               not reachable."

       ::= { ipfixExportEntry 1 }

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 08 May 2009 11:28:45 +0200

Dear Atsushi,

You propose to split ipfixExportMemberType from -06 into two objects
ipfixExportGroupType and ipfixExportMemberType with several
interdependencies specified in the description clauses.
At first sight, this does not seem to be easier to understand than the
table structure in -06.

Regards,
Gerhard

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

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
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: Atsushi Kobayashi <[email-masked]>
Date: Fri, 08 May 2009 20:05:52 +0900

Hi Gerhard,

On Fri, 08 May 2009 11:28:45 +0200

> At first sight, this does not seem to be easier to understand than the

Yes.

Section 5.4 mentions tuple (ipfixExportIndex, ipfixMeteringProcessCacheId,
ipfixTemplateObservationDomainId) indicates transport session group, but
section 7 MIB structure does not seem to indicate what transport session
group is.

Although DESCRIPTION in ipfixExportTable mentions that "Thanks to the
ipfixExportIndex the exports can group one or more Transport Sessions to
achieve a special functionality like failover management, load-balancing
etc.", actual table structure does not seem to group transport sessions
by ipfixExportIndex. 

When I would like to look for which transport sessions belong to some
specified transport session group, I have to see all of export table.

For example, all of transport sessions belonging to the following
transport session group (9:ipfixMeteringProcessCacheId,
3:ipfixTemplateObservationDomainId, 7:ipfixExportIndex)
may be scattered in the export table. It does not allow us to utilize
indexes of MIB structure.

    ipfixExportTable (5)
    |
    +- ipfixExportEntry (1)
       |
       +- index (9) (ipfixMeteringProcessCacheId)
          +- index (3) (ipfixTemplateObservationDomainId)
             +- index (257) (ipfixTemplateId)
             |  +- index (5) (ipfixTransportSessionIndex)
             |     +- index (7) (ipfixExportIndex)
             |        +- ipfixExportIndex (1) = 7
             |        +- ipfixExportMemberType (2) = 1 (primary)
             |
             +- index (257) (ipfixTemplateId)
             |  +- index (6) (ipfixTransportSessionIndex)
             |     +- index (9) (ipfixExportIndex)
             |        +- ipfixExportIndex (1) = 9
             |        +- ipfixExportMemberType (2) = 1 (primary)
             |
             +- index (264) (ipfixTemplateId)
             |  +- index (5) (ipfixTransportSessionIndex)
             |     +- index (8) (ipfixExportIndex)
             |        +- ipfixExportIndex (1) = 8
             |        +- ipfixExportMemberType (2) = 2 (secondary)
             |
             +- index (273) (ipfixTemplateId)
             |  +- index (11) (ipfixTransportSessionIndex)
             |     +- index (7) (ipfixExportIndex)
             |        +- ipfixExportIndex (1) = 7
             |        +- ipfixExportMemberType (2) = 2 (secondary)
             |
             +- index (289) (ipfixTemplateId)
                +- index (11) (ipfixTransportSessionIndex)
                   +- index (8) (ipfixExportIndex)
                      +- ipfixExportIndex (1) = 8
                      +- ipfixExportMemberType (2) = 1 (primary)

Regards,

Atsushi KOBAYASHI

---

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 May 2009 10:33:03 -0700

Hi -

> From: "Atsushi Kobayashi" <[email-masked]>
> To: "Thomas Dietz" <[email-masked]>
> Cc: "IETF IPFIX Working Group" <[email-masked]>; "MIB Doctors (E-mail)" <[email-masked]>
> Sent: Thursday, May 07, 2009 10:46 PM
> Subject: Re: [MIB-DOCTORS] [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt(ipfixExportEntry)
...
> > Since I have only libsmi (which does not catch this) I did not realize it.

This smicng warning can be misleading.  There is no SMI requirement, nor is
there even a recommendation, for having "a consistent indexing scheme."
The order of indexes should be determined by:
  (1) the use cases for retrieving subsets of the table
  (2) ease of access control policy formulation.

Making index order "consistent" can potentially defeat both of these
objectives.

Randy

---

From: Atsushi Kobayashi <[email-masked]>
Date: Mon, 11 May 2009 04:14:33 +0900

Hi Randy, Gerhard, Thomas and all,

> Making index order "consistent" can potentially defeat both of these

Thank you for your comments.

From viewpoint of (1), my conclusion is to keep the order of 3 indexes
like that in -05 draft.
- ipfixExportIndex,
- ipfixMeteringProcessCacheId,
- ipfixTemplateObservationDomainId,

It is more suitable than my proposal.

Regards,

 Atsushi KOBAYASHI

---