Subject: [IPFIX] IPFIX MIB review

From: Benoit Claise <[email-masked]>
Date: Mon, 16 Oct 2006 20:32:27 +0200

Dear all,

I reviewed the current IPFIX MIB (draft-dietz-ipfix-mib-00.txt).
I sent the editorial details directly to Thomas.
Feel free to start a new email thread with one of the point below.

1.  Section 3, IPFIX Documents Overview.

I would insert the second paragraph of section 2 at the end of this 
section., once we have defined the IPFIX document overview.
Otherwise, you defined twice the information.

2. Section 5, terminology
   The definitions of the basic terms like IP Traffic Flow, Exporting
   Process, Collecting Process, Observation Points, etc. are
   semantically identical with those found in the IPFIX requirements
   document [RFC3917]. 
It might be better to reference [IPFIX-PROTO], which is a normative 
reference anyway.

3.  Section 6.1.1, the Reporting Group
"ipfixCollectorGroupTable contains only indexes " I don't understand 
what it means

4. Section 6.1.2 the Instance Group

   The ipfixTemplateTable lists all data templates that are used by the
   IPFIX exporter.  It has two indices.  The first one is the template
   id and the second one is just a running index for the field ids
   listed in the table.  So the ipfixTemplateEntry.4.x will list all
   field ids used for template id 4 in the order given by x.

   ipfixTemplateEntry OBJECT-TYPE
       SYNTAX      IpfixTemplateEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the ipfixTemplateTable."
       INDEX { ipfixTemplateId, ipfixTemplateIndex }
       ::= { ipfixTemplateTable 1 }

Is there no conflict with the new definition of the template Id in 
[IPFIX-PROTO], as the templateId is unique per Transport Session?

      Template ID 
          Each of the newly generated Template Records is given a unique  
          Template ID.  This uniqueness is local to the Transport 
          Session and Observation Domain that generated the Template ID.  
          Template IDs 0-255 are reserved for Template Sets, Options 
          Template Sets, and other reserved Sets yet to be created.  

If a transport session restarts, then...

5.  -- Collector Group Table, ipfixCollectorGroupTable OBJECT-TYPE
I don't see what we gain with this group?
If this group contains several entries, are these multiple exports to 
all the entries.
I think this group only makes sense if we defined the notion of backup 
versus multiple versus load-balancing export in there.

6. And again the discussion about read-write versus read-only.
ipfixCollectorTable, ipfixCollectorGroupTable, ipfixTemplateTable, 
etc... are read-write.
Shall we limit the read-only with the "Units of Conformance"?

7. ipfixInstanceReportingProcessId

   ipfixInstanceReportingProcessId OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The process id of the reporting process used by this
            instance."
       ::= { ipfixInstanceEntry 10 }

There is no Reporting Process Id in IPIFX, and it dissapeared from PSAMP.
And I'm not sure what this adds to the MIB.

Note that the editorial changes have been sent directly to Thomas.

8. ipfixInstancePacketsDropped
   ipfixInstancePacketsDropped OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of packets dropped while filtering/sampling
            packets."
       ::= { ipfixInstanceEntry 8 }

This one should be part of the PSAMP MIB, right?

9. There is something missing. As defined in the CISCO NETFLOW MIB

    NfInterfaceDirectionTypes ::= TEXTUAL-CONVENTION
        STATUS  current
        DESCRIPTION        "Defines different types of interface configuration."
        SYNTAX  INTEGER{
                interfaceDirNone(0),
                interfaceDirIngress(1),
                interfaceDirEgress(2),
                interfaceDirBoth(3)
        }

    cnfCIInterfaceTable OBJECT-TYPE
        SYNTAX      SEQUENCE OF CnfCIInterfaceEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION        "This table provides Netflow Enable information per interface."
        ::= { cnfCacheInfo <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfCacheInfo> 1 }

    cnfCIInterfaceEntry OBJECT-TYPE
        SYNTAX     CnfCIInterfaceEntry
        MAX-ACCESS not-accessible
        STATUS     current
        DESCRIPTION        "A conceptual row in the cnfCIInterfaceEntry <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfCIInterfaceEntry>."
        INDEX { ifIndex <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=ifIndex> }
        ::= { cnfCIInterfaceTable <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfCIInterfaceTable> 1}

    CnfCIInterfaceEntry ::= SEQUENCE {
            cnfCINetflowEnable <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfCINetflowEnable>              NfInterfaceDirectionTypes
         }

    cnfCINetflowEnable OBJECT-TYPE
        SYNTAX      NfInterfaceDirectionTypes
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION        "Indicates whether the netflow feature is enabled for this
             interface, and if so, in which directions."
        ::= { cnfCIInterfaceEntry <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfCIInterfaceEntry> 1 }

10. Do we want to foresee the version already

  IpfixCollectorEntry ::= SEQUENCE {
           ipfixCollectorIndex             Integer32,
           ipfixCollectorDstIpAddressType  InetAddressType,
           ipfixCollectorDstIpAddress      InetAddress,
           ipfixCollectorDstProtocol       Integer32,
           ipfixCollectorDstPort           Integer32,
           ipfixCollectorReportsSent       Integer32,
           ipfixExportVersion               Integer32    ???????????????????
           ipfixCollectorRowStatus         RowStatus
       }

11. only ipfixTemplateRowStatus  is read-write in this table
 
   IpfixTemplateEntry ::= SEQUENCE {
           ipfixTemplateId          Integer32,
           ipfixTemplateIndex       Integer32,
           ipfixTemplateFieldId     Integer32,
           ipfixTemplateRowStatus   RowStatus
       }
 
   ipfixTemplateId OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  not-accessible        
<--------------------------------------------------
       STATUS      current
       DESCRIPTION
           "The unique identifier for the template."
       REFERENCE
           "draft-ietf-ipfix-sample-tech-04.txt, Section 5.1"
   -- Editor Note: get reference right!
       ::= { ipfixTemplateEntry 1 }
 
   ipfixTemplateIndex OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  not-accessible        
<--------------------------------------------------
       STATUS      current
       DESCRIPTION
           "The locally arbitrary, but unique identifier of a field Id
            in the template identified by ipfixTemplateId.
 
            The value is expected to remain constant at least from one
            re-initialization of the entity's network management system
            to the next re-initialization."
       ::= { ipfixTemplateEntry 2 }

  ipfixTemplateFieldId OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only        
<--------------------------------------------------
       STATUS      current         
       DESCRIPTION
           "The Field Id at position ipfixTemplateIndex in the template
            ipfixTemplateId. This implicitly gives the data type and
            state values that are exported."
       REFERENCE
           "draft-ietf-ipfix-sample-tech-04.txt, IPFIX/PSAMP INFO MODEL"
   -- Editor Note: get reference right!
       ::= { ipfixTemplateEntry 3 }
 
   ipfixTemplateRowStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The status of this row of the table."
       ::= { ipfixTemplateEntry 4 }

Only ipfixTemplateRowStatus  is read-write in this table. What does it 
mean? Can only deleted by SNMP? And not created?

12. We would really need some examples of the instance and method chain 
group

13. In ipfixReporting, I really would like to see some stats.
Coming from the NetFlow MIB:

    cnfESExportRate OBJECT-TYPE
        SYNTAX     Counter32
        UNITS      "bytes per second"
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of Bytes exported per second."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 2 }

    cnfESRecordsExported OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of flow statistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=statistics> records which were exported."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 3 }

    cnfESPktsExported OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of packets (udp datagrams) which were exported."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 4 }

    cnfESPktsFailed OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of times a flow record could not be exported because of
             a pak allocation failure."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 5 }

    cnfESPktsDropped OBJECT-TYPE
        SYNTAX     Counter32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION        "Number of export packets which were dropped at the time of
             ipwrite operation. The reasons for this failure are no FIB,
             adjacency failure, MTU failed, enqueue failed, IPC failed etc."
        ::= { cnfExportStatistics <http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cnfExportStatistics> 6 }

Note: the collectExporterStatisTable  should be aligned with the stats on the exporter. I mean: we should be able to compare the statistics on the exporter and the collector.

   collectExporterStatisEntry OBJECT-TYPE
       SYNTAX      CollectExporterStatisEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "Defines an entry in the collectExporterStatisTable"
       INDEX { collectExporterIndex,
               collectExporterDstPort }
       ::= { collectExporterStatisTable 1 }
 
   CollectExporterStatisEntry ::=
       SEQUENCE {
           collectExporterDstPort           Integer32,
           collectExporterProcessId         Integer32,
           collectExporterRcdPackets        Counter32,
           collectExporterRcdBytes          Counter32,
           collectExporterRcdMessages       Counter32,
           collectExporterDiscardMessages   Counter32,
           collectSessionElapsedTime        Gauge32,
           collectExporterRcdFlows          Counter32,
           collectExporterRcdTemplates      Counter32,
           collectExporterStatisRowStatus   RowStatus

 14. collectExporterTable  

   collectExporterTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   CollectExporterEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists Exporters that received by collecting
           process. This process manages them."
       ::= { collectExporter 1 }

  CollectExporterEntry ::=
       SEQUENCE {
           collectExporterIndex             Integer32,
           collectExporterSrcIpAddrType     InetAddressType,
           collectExporterSrcIpAddr         InetAddress,
           collectExporterProtocol          Integer32,
           collectExporterSrcPort           Integer32,
           collectLifeTimeTemplate          Integer32,
           collectExporterRowStatus         RowStatus
       }

What is the goal of that MIB table.
As this read-write, it means that I can _configure _on my Collector 
which Exporter I'm receiving info from. Is this supposed to serve as an ACL?
I would not have any problems if that MIB table would be read-only, 
simply listing the Exporters the Collector receives info from.
Same question for the collectObservDomainStatisTable  .

15. I think that we are missing the observation domain as an index in 
many tables
Example: as the Template IDs are unique per Observation Domain, 
ipfixTemplateTable must contains the O.D.id as an index
Example: ipfixInstanceTable
On the other hand, I don't clearly understand the goal of 
collectObservDomainStatisTable. Should we simply add the O.D.id to the 
collectExporterStatisTable  and combine those stats?

16.
   collectExporterStatisEntry OBJECT-TYPE
       SYNTAX      CollectExporterStatisEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "Defines an entry in the collectExporterStatisTable"
       INDEX { collectExporterIndex,
               collectExporterDstPort }

I don't understand why we have two indexes in this table? Isn't the 
collectExporterIndex enough? (next to the O.D.id: see point 16)

17.

   collectMeteringProcessId OBJECT-TYPE
       SYNTAX      Integer32(1..2147483647)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "It uses the Metering Process id in the received
           IPFIX message. It should be zero, if IPFIX message don't
           specify Metering Process id."
       ::= { collectObservDomainStatisEntry 2 }

The IPFIX Message doesn't specify the Metering Process id, so it will 
always be zero. So I would not even mention it.
And remove it as index in collectObservDomainStatisTable  and 
collectTemplateStatisticsTable 

18. collectTemplateStatisticsTable 
Again, why is there a rowStatus in that table?

19.

collectTemplateRcdTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   CollectTemplateRcdEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
          "This table lists templates that are received by the
           collecting process. This process manages them."
       ::= { collectTemplate 2 }
 
   collectTemplateRcdEntry OBJECT-TYPE
       SYNTAX      CollectTemplateRcdEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the collectTemplateRcdTable"
       INDEX {
           collectExporterIndex,
           collectObservDomainId,
           collectMeteringProcessId,
           collectTemplateRcdId,
           collectTemplateRcdIndex }
       ::= { collectTemplateRcdTable 1 }

   CollectTemplateRcdEntry ::=
       SEQUENCE {
           collectTemplateRcdIndex       Integer32,
           collectTemplateRcdInfoEltId   Integer32,
           collectTemplateInfoEltLength  Integer32,
           collectTemplateRcdRowStatus   RowStatus
       }

I'm wondering why we have this complex table (5 indexes) simply to 
display how the templates decode.
Somehow, I failed to find a business case for this table.
On the top of that, the template id are unique per transport session, 
missing in the index.

Regards, Benoit.

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