Subject: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Dec 2014 15:18:30 +0100

Hi,

here is my review of draft-ietf-ipfix-mib-variable-export-07. Most of
the comments are editorial or bug fixes. There is only one real
technical concern related to the encoding of BITS. The current I-D
uses a 64-bit unsigned integer, which limits things to 64 bit
positions. The SMIv2 does not have this limit - it only warns about
bit positions in excess of 128.

- RFC4293 is listed as a normative reference but as far as I can tell
  it is only used in an example. I suggest to make this an informative
  reference.

- p3: 2nd paragraph Introduction: I am not sure the statement "there
  are no dependencies between the SMIv2 and the SNMP protocol" is
  correct.  Perhaps the simplest fix is to simply delete the whole
  paragraph.

- p4: 1st paragraph Motivation: The 2nd sentence is hard to follow.

- p5: s/does not specify SNMP notifications/does not specify how to
  carry SNMP notifications in IPFIX/

- p9: s/in a certain MIB/in a certain MIB module/

- p10: s/may be also be/may also be/

- p10: s/described by the MIB./described by the MIB module./

- p14: s/when when/when/

- p14: s/references sections/referenced sections/

  The fact that every listed item refers to two sections may be a bit
  confusing, perhaps change to

  o  mibIndexIndicator (defined in Section 5.8.5, example in Section 11.2.2.3)

- p20: It took me a while to spot the difference between Fig. 7 and
  Fig.8 (I did not immediately spot that the fields are
  swapped). Perhaps mention this more explicitly in the last paragraph
  on p19?

     Figure 7 shows an IPFIX Options Template Set using Scope Existing
     IFPIX IE and a Non Scope mibObjectValueInteger IE, while Figure 8
     shows an IPFIX Options Template Set using a Scope
     mibObjectValueInteger IE and a Non Scope Existing IFPIX IE.

- p12: s/name of the MIB/name of the MIB module/

- p26: s/present the same order/present in the same order/

- p32: s/not defined as possible/not possible/

- p37: s/CISCO-PROCESS_MIB/CISCO-PROCESS-MIB/

- p45: s/ifMTU/ifMtu/ (this shows up several time, do a global replace)

- p46: Why is the Field Length of mibObjectValueOctetString set to 16?
       The interface names in general have variable length.

- p47: why 'ifName = ""'?

- p52: s/index by IEs:/indexed by IEs:/

- p58: The VLEN and the OID value seem to be wrong. I think this should
       be VLEN=10 and the OID value 06082B060102010E0A01.

- p61: I would have named SNMPtotalCounter simply snmpCounter and I
       would have named SNMPgauge snmpGauge. If this change is
       adopted, then these names needs to be changed in several
       places.

- p64: The encoding of mibObjectValueBits may need to specify how the
       bit positions are counted. That said, there is an issue here
       with using unsigned64. RFC 2578 does not restrict the bit
       positions, it only warns that using bit positions in excess of
       128 may cause interoperability problems. The IPFIX I-D
       essentially limits this to 64 bits. The obvious solution is to
       follow the SNMP encoding rules that encode bits into an octet
       string (an octetArray in IPFIX speak).

- p67: s/as defined in a MIB//

- p68: OLD

       Description: A non-negative sub-identifier.  One Sub number from
       an Object Identifier (OID).

       NEW

       Description: A non-negative sub-identifier of an Object
       Identifier (OID).

- p69: s/was retrieved from SNMP/was retrieved from the MIB/

- p70: s/could be sampled by SNMP/has been sampled/

- p70: s/SNMP sampling time/sampling time/

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Paul Aitken <[email-masked]>
Date: Wed, 17 Dec 2014 16:05:52 +0100

Thanks for this Juergen. I'll produce an updated version for the editorial issues.

For the BITS issue, the largest IPFIX types are currently 64 bits (ie, signed64 / unsigned64). Although we could request a 128-bit type, we're simply moving the absolute limit along without solving the underlying issue.

Do you know what size the largest BITS object is today? Would it be acceptable to limit the size that can be exported in IPFIX to the first 64 or 128 bits?

Thanks,
P.

> here is my review of draft-ietf-ipfix-mib-variable-export-07. Most of the
> comments are editorial or bug fixes. There is only one real technical concern
> related to the encoding of BITS. The current I-D uses a 64-bit unsigned integer,
> which limits things to 64 bit positions. The SMIv2 does not have this limit - it only
> warns about bit positions in excess of 128.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Dec 2014 16:48:24 +0100

> For the BITS issue, the largest IPFIX types are currently 64 bits (ie, signed64 / unsigned64). Although we could request a 128-bit type, we're simply moving the absolute limit along without solving…

SNMP encodes the bits into an octet string - an octetArray in
IPFIX. Could this be done here as well?
 
> Do you know what size the largest BITS object is today? Would it be
> acceptable to limit the size that can be exported in IPFIX to the
> first 64 or 128 bits?

The first question can't be answered so I can't answer the second. It
would be best, though, if IPFIX would not have to introduce a limit.
Would an octetArray not work?

/js

---

From: Brian Trammell <[email-masked]>
Date: Wed, 17 Dec 2014 16:50:55 +0100

If BITS really isn't intended to encode integers with numeric or flag semantics, then yes, it should be encoded as an octetArray.

Cheers,

Brian
 
> On 17 Dec 2014, at 16:48, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Wed, 17 Dec 2014 23:18:21 +0100

Juergen, Brian, thanks both - that's what I'll do.

P.

> If BITS really isn't intended to encode integers with numeric or flag
> semantics, then yes, it should be encoded as an octetArray.
> 
> Cheers,
> 
> Brian
> 
> > On 17 Dec 2014, at 16:48, Juergen Schoenwaelder
> <[email-masked]> wrote:
> >
> >> For the BITS issue, the largest IPFIX types are currently 64 bits (ie,
> >> signed64 / unsigned64). Although we could request a 128-bit type, we're
> >> simply moving the absolute limit along without solving the underlying issue.
> >
> > SNMP encodes the bits into an octet string - an octetArray in IPFIX.
> > Could this be done here as well?
> >