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

From: Paul Aitken <[email-masked]>
Date: Sun, 26 Oct 2014 15:50:57 +0000

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.

> 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.

> 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. 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. 
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.

Expressed another way, we've already created duplication; now we have to 
live with it.

> 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.

> 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.

> 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,
P.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 27 Oct 2014 13:07:13 +0100

On 26 Oct 2014, at 16:50, Paul Aitken <[email-masked]> wrote:

> Juergen Schoenwaelder is a co-author of this draft as an SNMP expert for exactly these reasons.
> 
> 
> 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.

> Although this was already stated in the Abstract, I've added a clear list of goals to the end of section 1:
> 

Thanks for moving this into the Intro as well, this addresses my concern.

> The mechanism _can_ be used like that.

Can be, yes. Is it the express intention of the authors of the draft to do so?

> 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.

> 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. 

>   stream as their associated Templates.

Excellent, thanks.

> 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
> 

Yep, looks good, thanks.

>   required by any existing Data Templates.

Thanks.

Cheers,

Brian

---

From: Rocco Caputo <[email-masked]>
Date: Mon, 27 Oct 2014 12:36:41 +0000

> On Oct 27, 2014, at 08:07, Brian Trammell <[email-masked]> wrote:
> 
> 

Collector processes are under constant pressure to scale higher.  As described here, the mapping seems to centralize a burden that could remain distributed.  It also seems that exporters can statically map the data they're configured to export, while collectors developed for heterogeneous enterprise-scale environments must dynamically be capable of handling everything the protocol can provide.

-- 
Rocco Caputo <[email-masked]>

---

From: Paul Aitken <[email-masked]>
Date: Thu, 30 Oct 2014 14:01:37 +0000

Brian,

> 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?

> ...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 com…

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.

> 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.