Subject: [IPFIX] IPFIX MIB design question

From: Benoit Claise <[email-masked]>
Date: Thu, 25 Jan 2007 10:21:01 +0100

Dear all,

We've got the following question regarding the design of our IPFIX MIB.
Should we combine the statististics and the configuration of an IPFIX 
"components" into a single table? Or should we keep two separate tables?

Let me explain with an example: ipfixTemplateTable and 
ipfixTemplateStatsTable 

   ipfixTemplateTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF IpfixTemplateEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists the templates that are transmitted or
           received by the exporting or collecting process."
      INDEX       {
           ipfixTransportSessionIndex,
           ipfixObservationDomainId,
           ipfixTemplateId
       }
       ::= { ipfixObjects 3 }
 
   ipfixTemplateEntry OBJECT-TYPE
       SYNTAX      IpfixTemplateEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the ipfixTemplateTable"
       INDEX       {
           ipfixTransportSessionIndex,
           ipfixObservationDomainId,
           ipfixTemplateId
       }

   ipfixTemplateStatsTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF IpfixTemplateStatsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists statistics objects per template.
           The indexes must match an entry in the ipfixTemplateTable."
       ::= { ipfixObjects 7 }
 
   ipfixTemplateStatsEntry OBJECT-TYPE
       SYNTAX      IpfixTemplateStatsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the ipfixTemplateStatsTable"
       INDEX       {
           ipfixTransportSessionIndex,
           ipfixObservationDomainId,
           ipfixTemplateId
       }
       ::= { ipfixTemplateStatsTable 1 }
 
   IpfixTemplateStatsEntry ::=
       SEQUENCE {
           ipfixTemplateDataRecords Counter32
       }

In this example, we see 2 tables (one for configuration, one for 
statistics) with the same indexes.
So, should we:
- combine the two tables into a single one?
- have two different tables as described?
- have two different tables with an AUGMENT? (when I see RFC 4181 
section 4.6.4 or RFC 2578 section 7.8.1, this solution seems more 
appropriate that the previous one)

Note that we've got the same question for other tables in our MIB:
    ipfixObservationDomainTable and ipfixObservationDomainStatsTable
    ipfixTransportSessionTable  and ipfixTransportSessionStatsTable 

The example with ipfixTemplateTable and ipfixTemplateStatsTable could 
lead to the (simple) answer: since there is just one entry in 
ipfixTemplateStatsTable, it makes sense to combine the MIB tables. To 
express that this is not always the case in our MIB, let me show the 
entries for ipfixTransportSessionTable  and ipfixTransportSessionStatsTable

   IpfixTransportSessionEntry ::=
       SEQUENCE {
          ipfixTransportSessionIndex                  Integer32,
          ipfixTransportSessionProtocol               Integer32,
          ipfixTransportSessionAddressType            InetAddressType,
          ipfixTransportSessionSourceAddress          InetAddress,
          ipfixTransportSessionDestinationAddress     InetAddress,
          ipfixTransportSessionSourcePort             Integer32,
          ipfixTransportSessionDestinationPort        Integer32,
          ipfixTransportSessionSctpAssocId            Unsigned32,
          ipfixTransportSessionTemplateRefreshTimeout Unsigned32,
          ipfixTransportSessionOptionTemplateRefreshTimeout Unsigned32,
          ipfixTransportSessionGroupId                Unsigned32,
          ipfixTransportSessionGroupMemberType        INTEGER,
          ipfixTransportSessionStatus                 INTEGER

   IpfixTransportSessionStatsEntry ::=
       SEQUENCE {
           ipfixTransportSessionPackets           Counter32,
           ipfixTransportSessionBytes             Counter32,
           ipfixTransportSessionMessages          Counter32,
           ipfixTransportSessionDiscardedMessages Counter32

Please advice. I've been looking around and could not find the answer.

Regards, Benoit

-----------------------------------------------------------

http://www.rfc-editor.org/rfc/rfc4181.txt

  4.6.4.  Conceptual Table Definitions

   RFC 2578 Sections 7.1.12 and 7.1.12.1 specify the rules for defining
   conceptual tables, and RFC 2578 Sections 7.7, 7.8, and 7.8.1 specify
   conceptual table indexing rules.  The following guidelines apply to
   such definitions:

   - For conceptual rows:

     - If the row is an extension of a row in some other table, then an
       AUGMENTS clause MUST be used if the relationship is one-to-one,
       and an INDEX clause MUST be used if the relationship is sparse.
       In the latter case, the INDEX clause SHOULD be identical to that
       of the original table.

-----------------------------

http://www.ietf.org/rfc/rfc2578.txt?number=2578
7.8.1.  Relation between INDEX and AUGMENTS clauses

   When defining instance identification information for a conceptual
   table:

(1)  If there is a one-to-one correspondence between the conceptual rows
     of this table and an existing table, then the AUGMENTS clause
     should be used.

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

---

From: kobayashi atsushi <[email-masked]>
Date: Fri, 26 Jan 2007 12:01:39 +0900

Benoit,

I think that using "AUGMENTS" is good proposal.

I have looked for similar MIB object.
The relationship between mplsInSegmentTable and mplsInSegmentPerfTable in
RFC3813 serve as a good reference.
The mplsInSegmentPerfTable contains statistical information as follows.

mplsInSegmentPerfEntry  OBJECT-TYPE
   SYNTAX        MplsInSegmentPerfEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
       "An entry in this table contains statistical
        information about one incoming segment which is
        configured in the mplsInSegmentTable. The counters
        in this entry should behave in a manner similar to
        that of the interface.
        mplsInSegmentPerfDiscontinuityTime indicates the
        time of the last discontinuity in all of these
        objects."
   AUGMENTS  { mplsInSegmentEntry }
   ::= { mplsInSegmentPerfTable 1 }

MplsInSegmentPerfEntry ::= SEQUENCE {
    mplsInSegmentPerfOctets             Counter32,
    mplsInSegmentPerfPackets            Counter32,
    mplsInSegmentPerfErrors             Counter32,
    mplsInSegmentPerfDiscards           Counter32,

    -- high capacity counter
    mplsInSegmentPerfHCOctets           Counter64,

    mplsInSegmentPerfDiscontinuityTime  TimeStamp
   }

Best regards,
Atsushi KOBAYASHI

On Thu, 25 Jan 2007 10:21:01 +0100

> appropriate that the previous one)

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

---

From: kobayashi atsushi <[email-masked]>
Date: Fri, 26 Jan 2007 12:01:39 +0900

Benoit,

    -- high capacity counter

Best regards,
Atsushi KOBAYASHI

---