[IPFIX] Partial review of draft-ietf-ipfix-mib-variable-export-06

Brian Trammell <[email protected]> Fri, 15 Aug 2014 12:00:40 +0200

Newsgroups	gmane.ietf.ipfix
Message-ID	<[email protected]>

Greetings, all,

I've taken a look at the MIB variable export draft; apologies for the lateness of this review.

I am by no means an SNMP expert, and do not intend to become enough of one to be able to adequately review this document, so this review should be read with the caveat that I expect the document will receive adequate review from SNMP/SMI experts to catch any problems on that side of the fence. I've also therefore presumed that all unfamiliar terminology (e.g. "Conceptual Rows") is defined in the SNMP world.

The general approach -- using options data records to enhance template records on a per-information-element basis -- seems sound. Indexed MIB variables make this a bit more complicated than it otherwise would be but as far as I can tell the method for addressing this seems sound as well.

I'm a little concerned by the complexity of the proposed solution. However, I can't really separate accidental from essential complexity because I don't have a feel for how much of it is necessary in order to bolt the SNMP data model onto the side of the IPFIX protocol. So I presume the authors have made some effort to define the least complicated way to do so.

Given the large scope, I'm also concerned about scope creep. It's implicit but not explicitly clear in section 2 that the primary goal of this document is (1) to allow the correlation of SNMP- and IPFIX-MP- sourced data by exporting them together and (2) to allow SNMP push data from SNMP-only devices to be more easily integrated into IPFIX-based collection infrastructures.

What the mechanism in the document should _not_ be used for is to expand the IPFIX information model to also include the contents of all the various MIBs, such that SMI IEs could be used alongside IPFIX IEs to export information from non-SNMP sources of data. Otherwise we've created Yet Another Representation for lots of common IEs already in the IPFIX IE registry, which would significantly complicate the comparison and combination of data at collectors. The document needs to make this explicit, either in section 1 or 2.

The template management characteristics of the proposed mechanism still need some work as well.

Section 5.7 should consider SCTP features for template management explicitly: that MIB Field Options Data Records MUST be exported reliably. MIB Field Options Data Records MUST also be exported on the same stream as the templates with which they are associated. Even though reliability is implied by the requirement to place a MIB Field ODR in the same Message with its associated Template.

This may cause problems with environments with restricted Message sizes (i.e., UDP transport over IPv4 with unknown path MTU (576), even UDP transport over non-Jumbo Ethernet (1460), as the MIB Field ODRs for a given template may be quite large. The document should provide guidance as to what to do in this case.

Note also that over UDP this implies the MIB Field ODPs will need to be resent with every template. Given the side of MIB Field ODPs this may imply significantly increased overhead compared with RFC 7011 IPFIX.

The document ignores template withdrawal and ID reuse. Personally, I'm okay with this feature being mutually exclusive with template withdrawal and ID reuse, because withdrawal and reuse are impossible to implement in a way that guarantees interoperability and unambiguous interpretation of data values when not used with a reliable or selectively-reliable transport, and significantly complicate template management in any case. But the document either needs to state that this feature may not be used with withdrawal and ID reuse, or needs to explain what happens to MIB Field ODP state when a template is withdrawn.

Best regards,

Brian

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix

signature.asc (application/pgp-signature, 496 B)