[ipfix] Closing issues from IPFIX INFO AD review

[Juergen Quittek <[e-mail]>]

Dear all,

>From the AD review by Bert we had eight open issues left for
the IPFIX information model.  Please find them listed below
with proposed solutions for all of them except INFO-AD#4
which we are still discussing but expecting to close this week:

|INFO-AD#4: How to add new label types to the definition of
|           IE #46 mplsTopLabelType?
|
|>> - sect 5.6.9
|>>   How are new values of Labeltypes be added in the future?
|>>   last line in this section, remove "and IP addresses" ??
|>
|> INFO-AD#4:
|> I have no good answer on this comment. Does anyone else have?
|
|The issue is still under investigation.  Looks like the only
|solution is another number space maintained by IANA.


Comments are highly appreciated.

Thanks,

    Juergen


INFO-AD#1: Do reported statistics include or exclude the
           reporting IPFIX message?  Affected IEs are
               #40 exportedOctetTotalCount
               #41 exportedMessageTotalCount
               #42 exportedFlowTotalCount

>> - sect 5.2.3
>>   Is the message that contains this Information Element included in the
>>   count?? May want to make that clear for better interoperability.
>>   Same for some of the other exportXXXCounters
>
> INFO-AD#1:
> These IEs are specified to be compatible with NetFlow v9.
> I'm checking with my co-authors from Cisco which alternative
> was chosen for NF v9.
>
> When I have this information, I will remove the ambiguity
> from the descriptions of IEs
>     #40 exportedOctetTotalCount
>     #41 exportedMessageTotalCount
>     #42 exportedFlowTotalCount

Solution (by Benoit): Neither of them includes the reporting packet.

5.2.3.  exportedMessageTotalCount

   Description:
      The total number of IPFIX Messages that the Exporting Process
      successfully sent since the Exporting Process (re-)initialization
      to the Collecting Process receiving a report that contains this
      Information Element.  The reported number excludes the message
      that carries the counter value.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 41
   Status: current
   Units: messages

5.2.4.  exportedOctetTotalCount

   Description:
      The total number of octets that the Exporting Process successfully
      sent since the Exporting Process (re-)initialization to the
      Collecting Process receiving a report that contains this
      Information Element.  The value of this Information Element is
      calculated by summing up the IPFIX Message header length values of
      all IPFIX Messages that were successfully sent to the Collecting
      Process receiving a report that contains this Information Element.
      The reported number excludes octets in the message that carries
      the counter value.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 40
   Status: current
   Units: octets

5.2.5.  exportedFlowRecordTotalCount

   Description:
      The total number of Flows Records that the Exporting Process
      successfully sent as Data Records since the Exporting Process
      (re-)initialization to the Collecting Process receiving a report
      that contains this Information Element.  The reported number
      excludes flow records in the message that carries the counter
      value.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 42
   Status: current
   Units: flows


INFO-AD#2: Does IE #42 exportedFlowTotalCount report the number
           of flows or the number of flow records?

>> - sect 5.2.5
>>   Text says: number of flow records
>>   But in Units it says: flows
>>   So what is it?
>>   Same for sect 5.2.9
>
> INFO-AD#2:
> This is another NF v9 compatible IE.  As above, I will check
> and make sure that description and units are consistent.

Solution (by Benoit): It is the number of flow records.
We renamed the IE from exportedFlowTotalCount to
exportedFlowRecordTotalCount, see solution of INFO-AD#1.


INFO-AD#3: Is it OK to change dataty of IEs
               #16 bgpSourceAsNumber
               #17 bgpDestinationAsNumber
               #128 bgpNextAdjacentAsNumber
               #129 bgpPrevAdjacentAsNumber
           from unsiogned16 to unsigned32?

>> - Sect 5.6.3
>>   I worry about the fact that there is discussion already about AS numbers
>>   of 32-bit length. So are we future proof here?
>>   In the MIB/SMI world we have made it a 32bit unsigned, see
>>   InetAutonomousSystemNumber in RFC4001.
>
> INFO-AD#3:
> change data type of
>     #16  bgpSourceAsNumber
>     #17  bgpDestinationAsNumber
>     #128 bgpNextAdjacentAsNumber
>     #129 bgpPrevAdjacentAsNumber
> from unsigned16 to unsigned32.

Yes, it is.  Change applied.


INFO-AD#5: Explain in the capabilities and limitations of the
           different dateTimeXX data types.

>> - sect 5.5.x
>>   Would it be useful to add a line of text to explain how long
>>   (how many minutes, months, years) each granularity allows
>>   based on the underlying datatype?
>
> INFO-AD#5:
> I will work on a text suggestion.  We avoid duplication if we put
> this text to the data type descriptions in section 3.1.

I think the problem only applies to delta timers.
It is not relevant for absolute time stamps.
I appended a sentence to the paragraph in section 5.8
that discusses delta timer stamps:

   Time stamps flowStartDeltaMicroseconds and flowEndDeltaMicroseconds
   are relative time stamps only valid within the scope of a single
   IPFIX Message.  They contain the negative time offsets relative to
   the export time specified in the IPFIX Message header.  The maximum
   time offset that can be encoded by these delta counters is 1 hour, 11
   minutes, and 34.967295 seconds.


INFO-AD#6: Review last paragraph of section 7.

>>   You speak about an Appendix B as having a schema/example
>>   on how to extend. It is however (I think) the Schema
>>   for the currently assigned values.
>
> INFO-AD#6:
> Yes, but it should also be used for extensions.  However, I
> still need to investigate the XML schema issues that you posted
> in a different email.  I will come back to this issue, when
> the XML schema issue is closed.

OLD
   Appendix B defines an XML schema which may be used to create
   consistent machine readable extensions to the IPFIX information
   model.  This schema introduces a new namespace, which will be
   assigned by IANA according to RFC 3688.  Currently the name space for
   this schema is identified as http://www.ietf.org/ipfix.
NEW
   Appendix B defines an XML schema which was used for Appendix A where
   all Information Models defines by this docments are specified using
   XML.  This schema may also be used for specifying further Information
   Elements in future extensions of the IPFIX information model in a
   machine readable way.  The schema introduces a new namespace, which
   will be assigned by IANA according to RFC 3688.  Currently the name
   space for this schema is identified as http://www.ietf.org/ipfix.


INFO-AD#7: Elaborate security considerations

>> - Sect 8.
>>   I am pretty sure that the Security ADs will want to see
>>   more detail here. They probably want to understand which
>>   Information Elements contain sensitive data (and why it
>>   is sensitive) or privacy sensitive data (and why so).
>>   Probably similar to why they want to see that a MIB
>>   document lists the objects that are sensitive and
>>   why so and what the risks are if the data gets
>>   intercepted.
>
> INFO-AD#7:
> Let's come back to this after the security AD review.


INFO-AD#8: Appendix A is not formal specification.
           All text that says it is formal, needs to be changed.

>> The best that can be done with this is to confirm that it's well-formed XML.
>> It's NOT a specification in the formal sense of the word.
>
> INFO-AD#8:
> Agreed.  This needs to be fixed at several places in the draft.
> I will come back with text suggestions.

Depending on the context, I replaced 'formal' by either 'XML' or
'machine readable':

OLD
Appendix A.  Formal Specification of IPFIX Information Element

   This appendix contains a formal description of the IPFIX information
   model XML document.  Note that this appendix is of informational
   nature, while the text in section 4 generated from this appendix is
   normative.

   Using a formal and machine readable syntax for the Information model
   enables the creation of IPFIX aware tools which can automatically
   adapt to extensions to the information model, by simply reading
   updated information model specifications.
NEW
Appendix A.  XML Specification of IPFIX Information Elements

   This appendix contains a machine readable description of the IPFIX
   information model coded in XML.  Note that this appendix is of
   informational nature, while the text in section 4 (generated from
   this appendix) is normative.

   Using a machine readable syntax for the Information model enables the
   creation of IPFIX aware tools which can automatically adapt to
   extensions to the information model, by simply reading updated
   information model specifications.

OLD
Appendix B.  Formal Specification of Abstract Data Types

   This appendix containfs a formal description of the abstract data
   types to be used for IPFIX Information Elements and a formal
   description of the template used for defining IPFIX Information
   Elements.  Note that this appendix is of informational nature, while
   the text in sections 2 and 3 generated from this appendix is
   normative.
NEW
Appendix B.  XML Specification of Abstract Data Types

   This appendix containfs a machine readable description of the
   abstract data types to be used for IPFIX Information Elements and a
   machine readable description of the template used for defining IPFIX
   Information Elements.  Note that this appendix is of informational
   nature, while the text in sections 2 and 3 (generated from this
   appendix) is normative.



--
Help        mailto:[e-mail] and say "help" in message body
Unsubscribe mailto:[e-mail] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/