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

---

From: kobayashi atsushi <[email-masked]>
Date: Tue, 17 Oct 2006 14:30:47 +0900

Dear Benoit and all,

This thread is listed up No.6 comment "read-wite versus read-only".

> Shall we limit the read-only with the "Units of Conformance"?

It is OK that whole Collector-MIB module is "read-only", It is simply receiving
exporting data as you mention. But, I hope that the configurable parameters
of Exporter-MIB are "read-write" at least.
I wonder that the flow configurable parameters are "read-only", 
whereas packet sampling configurable parameters are "read-write" as PSAMP-MIB.

--- 
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: Tue, 17 Oct 2006 14:30:47 +0900

Dear Benoit and all,

---

---

From: kobayashi atsushi <[email-masked]>
Date: Tue, 17 Oct 2006 14:38:42 +0900

Dear Benoit and all,

This thread is listed up No.11 comment "Row status".

I simply imaged that the row of table is deleted or created by SNMP.
You mean that RowStatus in statistics table should be removed?
As statistic table shows only performance data that is not configurable
parameter, I think that Rowstatus is certainly needless.

---

---

From: kobayashi atsushi <[email-masked]>
Date: Tue, 17 Oct 2006 14:38:42 +0900

Dear Benoit and all,

---

---

From: kobayashi atsushi <[email-masked]>
Date: Tue, 17 Oct 2006 14:49:47 +0900

Dear Benoit and all,

I answer some of comments about COLLECTOR-MIB in inline.
They are 13, 14, 15, 16, 17, 18, and 19.

snip.

> 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.

I almost agree your comment. But, I have been considering three statistics tables
as follows. 
The Exporter statistics table will be changed session statstics table  in
consideration of backup multiple session between a Exporter and a Collector. 
Do you mean that SessionStatsTable should be aligned with Exporter-MIB?

(*) means index in this table.

 ipfixSessionStatsTable
  *ipfixExporterIndex
  *ipfixSessionId
   ipfixSessionPackets
   ipfixSessionBytes
   ipfixSessionMessages
   ipfixSessionDiscardMessages
   ipfixSessionFlows
   ipfixSessionTemplates
   ipfixSessionElapsedTime
 
 ipfixObdomainStats
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
   ipfixObdomainMessages
   ipfixObdomainFlows
   ipfixObdomainTemplates
   ipfixObdomainLatestSeqNumber
   ipfixObdomainDisorderdSeqNumbers

 ipfixTemplateStatsTable
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
  *ipfixTemplateId
   ipfixTempFlows
   ipfixTempReceivedTime

> Same question for the collectObservDomainStatisTable  .
OK, I will change "read-only" objects in collectExporterTable and
collectObservDomainStatisTable.

> collectExporterStatisTable  and combine those stats?

I will propose  collectObservDomainStatisTable as follows.
I think that it has three index in consideration of multiple ODID
exporting to the same session.

(*) means index in this table.

 ipfixObdomainStats
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
   ipfixObdomainMessages
   ipfixObdomainFlows
   ipfixObdomainTemplates
   ipfixObdomainLatestSeqNumber
   ipfixObdomainDisorderdSeqNumbers

> collectExporterIndex enough? (next to the O.D.id: see point 16)

I think that collectExporterIndex is enough after ODID discussion  in
mailing list. 
But, I think that ExporterStatisticsTable will be changed SessionStatisticsTable.
Is this table necessary?

> collectTemplateStatisticsTable 

I will remove this object in these table.

> Again, why is there a rowStatus in that table?
I will remove this object in these table.

> On the top of that, the template id are unique per transport session, 

I will propose following table. 

 ipfixTemplateTable
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixTemplateId
  *ipfixTemplateIndex
   ipfixTemplateFieldId
   ipfixTemplateFieldLength

---

---

From: kobayashi atsushi <[email-masked]>
Date: Tue, 17 Oct 2006 14:49:47 +0900

Dear Benoit and all,

snip.

 ipfixSessionStatsTable
  *ipfixExporterIndex
  *ipfixSessionId
   ipfixSessionPackets
   ipfixSessionBytes
   ipfixSessionMessages
 
 ipfixObdomainStats
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
   ipfixObdomainMessages
   ipfixObdomainFlows
   ipfixObdomainTemplates

 ipfixTemplateStatsTable
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
  *ipfixTemplateId
   ipfixTempFlows
   ipfixTempReceivedTime

 ipfixObdomainStats
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixObdomainId
   ipfixObdomainMessages
   ipfixObdomainFlows
   ipfixObdomainTemplates

 ipfixTemplateTable
  *ipfixExporterIndex
  *ipfixSessionId
  *ipfixTemplateId
  *ipfixTemplateIndex
   ipfixTemplateFieldId
   ipfixTemplateFieldLength

---

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Oct 2006 09:07:14 +0200

Dear Kobayashi,
> exporting data as you mention. 
I'm happy that we agree, as you confused me. At some point in time, I 
was thinking that you wanted to configure Exporters information on the 
Collector via the Collector MIB, which is clearly not possible as there 
is no configuration mechanism in IPFIX.
> But, I hope that the configurable parameters
Some of them make sense, I agree. I'm wondering where to stop. Shall we 
allow everything to be configure via SNMP on the Exporter?
Maybe the solution is to make all OID read-write, and that the "Units of 
Conformance" specify that the read-only is the minimum to implement.
That way, we clearly specify how to use the MIB for configuration, while 
not mandating it... in case there is a more appropriate solution (NETCONF?)

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Oct 2006 09:07:14 +0200

Dear Kobayashi,

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Oct 2006 09:14:54 +0200

Dear Kobayashi,
> I simply imaged that the row of table is deleted or created by SNMP.
My point is: how could you create a new entry in the specific case, as 
you can only read ipfixTemplateFieldId, and not set it.
> You mean that RowStatus in statistics table should be removed?
Yes, unless you want to say: I'm continuously monitor the stats (which 
update themselves automatically), but I can use the RowStatus "delete" 
to delete a specific entry to "clear" the stats.
However, even if possible, I don't think RowStatus was foreseen for that 
case as a single delta of two polling would return the right information.

> parameter, I think that Rowstatus is certainly needless.
We agree.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Oct 2006 09:14:54 +0200

Dear Kobayashi,

We agree.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Oct 2006 09:30:16 +0200

Dear Kobayashi,

Many thanks for your work on the MIB.
See inline.
> Do you mean that SessionStatsTable should be aligned with Exporter-MIB?
At first glance, I would think it makes sense if we want to be able to 
compare stats. I would see a good case for UDP
>    ipfixSessionDiscardMessages
I'm wondering whether we need the O.D. as an index in the table above: 
maybe in case of multiple line cards exporting via the same session?
If this is the case, the table above and below could potentially be 
combined.
What's happening when a session is not active anymore. Is it simply 
removed form that table? Or kept for some time? If the latter, do you 
want to have "active/inactive" or the notion of time? This remark will 
be important for the comment 19 below.
> But, I think that ExporterStatisticsTable will be changed SessionStatisticsTable.
You're correct.
> I will propose following table. 
Somehow, I failed to find a business case for this table. How do you plan to use this info?
If this is to be able to decode a template, you have to pay attention that the templateId are unique per SessionId?
So if you have a new session, you might have new templateId. Hence you want to keep some template definition for some time. Hence you must have the notion of active/inactive (or time information) in the session table.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Oct 2006 09:30:16 +0200

Dear Kobayashi,

You're correct.

Regards, Benoit.

---

From: kobayashi atsushi <[email-masked]>
Date: Tue, 17 Oct 2006 17:59:43 +0900

Dear Benoit and all,

I wrote my comment inline.

On Tue, 17 Oct 2006 09:07:14 +0200

> not mandating it... in case there is a more appropriate solution (NETCONF?)

You mean that minimum conformance set is "read-only"?
We can show the implementation of some conformance IPFIX device 
by defining MIB. That MIB should be reflected from conformance IPFIX.
If read-only, we can not recognize whether each parameter is 
implemented parameter of device, or configurable parameter.
NETCONF is better solution, but NETCONF data model is created based on 
this MIB module. 

Regards,
Atsushi KOBAYASHI

---

---

From: kobayashi atsushi <[email-masked]>
Date: Tue, 17 Oct 2006 17:59:43 +0900

Dear Benoit and all,

Regards,
Atsushi KOBAYASHI

---

---

From: kobayashi atsushi <[email-masked]>
Date: Tue, 17 Oct 2006 18:49:46 +0900

Dear Benoit and all,

Please see inline.

snip

> If this is the case, the table above and below could potentially be 

You mean that each statistics parameter in the ipfixSessionStatsTable is
the result of aggregation of multiple ipfixObdomainStats in same session?

If yes, we can remove several parameters in ipfixSessionStatsTable.  But,
ipfixSessionElapsedTime is maintained in this table.

> be important for the comment 19 below.

I think that latter condition. I will propose another table as follows.

 ipfixSessionTable
  *ipfixExporterIndex
  *ipfixSessionId
   ipfixSessionStatus
   ipfixSessionProtocol
   ipfixSessionDstPort
   ipfixSessionSrcPort 

Above sessionId is kept with session statistics data for some time, after
session is down. We can see session status by retrieving ipfixSessionStatus
object.

snip

> So if you have a new session, you might have new templateId. Hence you want to keep some template definition for some time. Hence you must have the notion of active/inactive (or time information) i…

First of all, collecting process should keep template id with field
contents. 
And also, COLLECTOR-MIB maintains per template statistics data.
We can recognize each template is sort of template, such as IPv4,
IPv6, the number of label stack MPLS. Template statistics data is
valuable by seeing sort of template.
And also, another node can see what information elements are stored in
this collector. It can retrieve flow records adequately.

---

---

From: kobayashi atsushi <[email-masked]>
Date: Tue, 17 Oct 2006 18:49:46 +0900

Dear Benoit and all,

Please see inline.

snip

 ipfixSessionTable
  *ipfixExporterIndex
  *ipfixSessionId
   ipfixSessionStatus
   ipfixSessionProtocol
   ipfixSessionDstPort
   ipfixSessionSrcPort 

snip

---

---

From: "Thomas Dietz" <[email-masked]>
Date: Thu, 19 Oct 2006 04:07:17 +0200

Dear Benoit,
 
find my comments inline

--
Thomas Dietz                       E-mail: [email-masked]
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
<http://www.netlab.nec.de/> 

  _____  

From: Benoit Claise [mailto:[email-masked]] 
Sent: Monday, October 16, 2006 8:32 PM
To: [email-masked]
Subject: [IPFIX] IPFIX MIB review

Dear all,

For comment 1 and 2 you are definetly right but I wanted to have the
sections there and to be filled even with a preliminary text. I agree we
need to update those sections after the work on the other documents is
finished.

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

You have the list of collectors where you could send your flow reports. But
an exporter could export the same flow record to multiple collectors for
redundancy or whatever reason. So I defined the that table to group
collectors together and then reference an index of this table at the
instance to indicate where the instance reports to. I guess this answers
also question 5 below.

      Template ID 

If this group contains several entries, are these multiple exports to all
the entries.

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"?

I just opened a new thread to explain the problem here. We might want to
have a writeable MIB. So for now I will remove all row status and make all
object read-only. We need to take a decission on this topics first and then
start a dicusion (if we agree to make it writeable) which object and tables
should be writable and which not.

Still a remainder from the old PSAMP MIB so i will delete this object.

It is definitely used in PSAMP. So I should state that.

 

    STATUS  current

    SYNTAX  INTEGER{

            interfaceDirNone(0),

            interfaceDirIngress(1),

            interfaceDirEgress(2),

            interfaceDirBoth(3)

    }

    STATUS      current

    DESCRIPTION        "This table provides Netflow Enable information per
interface."

    ::= { cnfCacheInfo
<http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Tran
slate&objectInput=cnfCacheInfo>  1 }

    STATUS     current

    DESCRIPTION        "A conceptual row in the cnfCIInterfaceEntry
<http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Tran
slate&objectInput=cnfCIInterfaceEntry> ."

    INDEX { ifIndex
<http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Tran
slate&objectInput=ifIndex>  }

    ::= { cnfCIInterfaceTable
<http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Tran
slate&objectInput=cnfCIInterfaceTable>  1}

        cnfCINetflowEnable
<http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Tran
slate&objectInput=cnfCINetflowEnable>
NfInterfaceDirectionTypes

     }

    MAX-ACCESS  read-write

    STATUS      current

    DESCRIPTION        "Indicates whether the netflow feature is enabled for
this

    ::= { cnfCIInterfaceEntry
<http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Tran
slate&objectInput=cnfCIInterfaceEntry>  1 }

 
Well, those object describe somehow the Observation Domain (if I am not
misleaded here).
So since the notion of Observation Domain is still missing in the MIB we
should place
this somewhere and somehow there.

Good point to add. 

 

 

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

Let's defer this discusion of how the access to different objects need to be
set to make them writeable until we made the basic desision (see above).

More than true.

    SYNTAX     Counter32

    UNITS      "bytes per second"

    MAX-ACCESS read-only

    STATUS     current

    ::= { cnfExportStatistics
<http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Tran
slate&objectInput=cnfExportStatistics>  2 }

    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=Tran
slate&objectInput=statistics>  records which were exported."

    ::= { cnfExportStatistics
<http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Tran
slate&objectInput=cnfExportStatistics>  3 }

    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=Tran
slate&objectInput=cnfExportStatistics>  4 }

    SYNTAX     Counter32

    MAX-ACCESS read-only

    STATUS     current

    DESCRIPTION        "Number of times a flow record could not be exported
because of

    ::= { cnfExportStatistics
<http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Tran
slate&objectInput=cnfExportStatistics>  5 }

    SYNTAX     Counter32

    MAX-ACCESS read-only

    STATUS     current

    DESCRIPTION        "Number of export packets which were dropped at the
time of

    ::= { cnfExportStatistics
<http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Tran
slate&objectInput=cnfExportStatistics>  6 }

Fine! I now that statistics are a little underrepresented right now. Every
comment/addition in this regard is welcome. 

 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.

Allignment of the two parts is an issue but it will take some time and I try
to carefully align the two part in the near future. 

 14. collectExporterTable  

  CollectExporterEntry ::=
       SEQUENCE {

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  .

As state already several times above: deffered!

15. I think that we are missing the observation domain as an index in many
tables

Agreed here. The MIB doesn't reflect the recent dicisions on Observation
Domain and Session. So those need to be integrated where needed.
 
16. 

17.

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  

19.

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.
 
Well you find the comments in Kobayashi-sans reply.

Regards, Benoit.

---

From: "Thomas Dietz" <[email-masked]>
Date: Thu, 19 Oct 2006 04:07:17 +0200

Dear Benoit,
 
find my comments inline

 

  _____  

Dear all,

 

      Template ID 

 

 

 

    STATUS  current

    SYNTAX  INTEGER{

            interfaceDirNone(0),

            interfaceDirIngress(1),

            interfaceDirEgress(2),

            interfaceDirBoth(3)

    }

    STATUS      current

    ::= { cnfCacheInfo

    STATUS     current

    INDEX { ifIndex

        cnfCINetflowEnable

     }

    MAX-ACCESS  read-write

    STATUS      current

  

Good point to add. 

 

 

 

More than true.

    SYNTAX     Counter32

    UNITS      "bytes per second"

    MAX-ACCESS read-only

    STATUS     current

    SYNTAX     Counter32

    MAX-ACCESS read-only

    STATUS     current

    SYNTAX     Counter32

    MAX-ACCESS read-only

    STATUS     current

    SYNTAX     Counter32

    MAX-ACCESS read-only

    STATUS     current

    SYNTAX     Counter32

    MAX-ACCESS read-only

    STATUS     current

 

 

 14. collectExporterTable  

  CollectExporterEntry ::=
       SEQUENCE {

 

16. 

17.

19.

 

Regards, Benoit.