Issues with ipfix's octetDeltaCount and packetDeltaCount size

[pavel-odintsov]

Hello!

After Wireshark investigation I found you use 32 bit (4 bytes) packets and bytes counter for IPFIX. But in reference standard http://www.iana.org/assignments/ipfix/ipfix.xhtml this counters defined as 64 bit.

Here you can find screenshot from the Wireshark:

Could you fix it?

[pavel-odintsov]

I checked ipfix from Juniper MX5-T and found 8byte counters for both fields.

[aabc]

This is standard compliant behavior. See http://tools.ietf.org/html/rfc5101

6.2.  Reduced Size Encoding of Integer and Float Types

   Information Elements containing integer, string, float, and
   octetarray types in the information model MAY be encoded using fewer
   octets than those implied by their type in the information model
   definition [RFC5102], [...]

   For instance, the information model [RFC5102] defines byteCount as an
   unsigned64 type, which would require 64 bits.  However, if the
   Exporter will never locally encounter the need to send a value larger
   than 4294967295, it may chose to send the value instead as an
   unsigned32. [...]

   This behavior is indicated by the Exporter by specifying a type size
   with a smaller length than that associated with the assigned type of
   the Information Element.  In the example above, the Exporter would
   place a length of 4 versus 8 in the Template.

     [...]  The reduction in size can be to
   any number of octets smaller than the original type if the data value
   still fits, i.e., so that only leading zeroes are dropped.  For
   example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or
   1 octet(s).

So the standard permit to use fewer than maximum bytes. You should check template to see actual byte size for element and not rely on 'unsigned64' type. Also, byte counters never wrap 32-bit value so there is no need for larger type.

[pavel-odintsov]

Thanks for a fast answer! I will implement support for fewer sized data.