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

[Paul Aitken <[e-mail]>]

Brian,

> On 26 Oct 2014, at 16:50, Paul Aitken <[e-mail]> wrote:
>
>> Brian, thanks for reviewing the draft. Feedback inline...
>>
>>> 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.
>> Juergen Schoenwaelder is a co-author of this draft as an SNMP expert for exactly these reasons.
>>
>>
>>> 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.
>> Recall that we proposed a couple of more complicated solutions in earlier versions of this draft; the current proposal is as straightforward and IPFIX compliant as we can make it.
> Yep, I'm happy with this. Just reacting more to the complexity that comes with indexing in MIB objects.
>
>>> 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.
>> Although this was already stated in the Abstract, I've added a clear list of goals to the end of section 1:
>>
>>    Therefore the primary goals of this document are:
>>
>>    o  to specify a way to complement IPFIX Data Records with Management
>>       Information Base (MIB) objects;
>>
>>    o  to avoid the need to define new IPFIX Information Elements for
>>       existing Management Information Base objects that are already
>>       fully specified;
>>
>>    o  to allow the correlation of SNMP- and IPFIX-MP- sourced data by
>>       exporting them together;
>>
>>    o  to allow SNMP push data from SNMP-only devices to be more easily
>>       integrated into IPFIX-based collection infrastructures.
> Thanks for moving this into the Intro as well, this addresses my concern.
>
>>> 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 mechanism _can_ be used like that.
> Can be, yes. Is it the express intention of the authors of the draft to do so?

Authors aside, what does the WG want? Ultimately the goal is to avoid 
creating new IPFIX IEs for each MIB that needs exported. Does that 
require considering MIBs as part of the info model?


>> Where existing IPFIX IEs have been already been created for MIBs, there will now be two ways to represent the exported data. It would be up to the metering or exporting process to decide which is the most appropriate. We can't mandate one over the other because existing exporters might prefer to use the IPFIX IEs while new devices exporting several MIBs would prefer not to be obliged to convert some of them into the equivalent IPFIX IEs.
> So I kind of get the intention here...
>
>> Collectors should understand the equivalence and map the IPFIX IE and the MIB object to the same internal entity, so there should be no difficultly in comparing or combining data.
> ...but it strikes me as a little unkind to publish this document as a "you can do this, collectors will handle the mess" without at least an appendix linking IEs in the present IANA registry to commonly-used MIB objects. But I'll step back and let people who write collectors for customers other than themselves comment on this statement.

If the WG wants an appendix, then it should be straightforward to add 
one. Unfortunately I'm pressed for time before the current meeting, so I 
can't do it immediately.


>> Expressed another way, we've already created duplication; now we have to live with it.
> Actually this seems to be closer to "we've already created duplication, so we can happily create more," which seems dangerous for sustainable interop.

What change, if any, would you like to see in the draft?

Thanks,
P.


>>> 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.
>> Thanks; I've clarified that in section 5.7:
>>
>>    When exporting over an SCTP transport [RFC4960], the MIB Field
>>    Options Data Records MUST be exported reliably and in the same SCTP
>>    stream as their associated Templates.
> Excellent, thanks.
>
>>> 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.
>> If the Message exceeds the MTU then you're stuck. Exceptionally in the case of reliable SCTP transport we could allow the MIB Field Options Template, MIB Field Options Data, Data Template, and Data Records, to be exported individually in that order, so I've added a new section:
>>
>> 5.7.1.  Large Messages
>>
>>    The requirement to export the MIB Field Options Template and MIB
>>    Field Options Data Records in the same IPFIX Message as any (Option)
>>    Template Record that uses a mibObjectValue Information Element may
>>    result in very large IPFIX Messages.
>>
>>    In environments with restricted Message sizes, and only when a
>>    reliable SCTP transport is being used, the MIB Field Options
>>    Template, MIB Field Options Data, Data Template, and Data Records,
>>    MAY be exported in separate Messages in the same SCTP stream,
>>    provided that their order is maintained.
> Yep, looks good, thanks.
>
>>> 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.
>> Indeed.
>>
>>
>>> 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.
>> I've added a new section 5.7.2 to cover this:
>>
>> 5.7.2.  Template Withdrawal and Reuse
>>
>>    Data Records containing mibObjectValue Information Elements MUST NOT
>>    be exported if their corresponding Data Template or MIB Field Options
>>    Template has been withdrawn, since the MIB Field Options Template
>>    MUST be exported in the same IPFIX Message as the Data Template which
>>    it annotates.
>>
>>    MIB Field Options Template IDs MUST NOT be reused while they are
>>    required by any existing Data Templates.
> Thanks.
>
> Cheers,
>
> Brian
>