Re: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-00.txt
Brian Trammell <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
hi, Benoit, Paul, Juergen, all, As the content of this document appears identical to draft-johnson-ipfix-mib-variable-export-04, my comments as to a more general extensible template mechanism (http://www.ietf.org/mail-archive/web/ipfix/current/msg06347.html and quoted below) apply as well to this draft. If the WG decides it doesn't make sense to use two SetIDs for this, I would suggest an alternate approach, completely compatible with vanilla 5101(-bis) IPFIX, which requires no new Set ID: simply use the extended type information mechanism from RFC 5610. Here a template may have multiple instances of the MIB OID Extension IE, then an Options Template describing records scoped by templateID, informationElementNumber, and informationElementIndex, containing a variable-length OID Information Element. (Again, I'm not sure how to handle indexing here but a mechanism similar to that described in the draft or in the message below should work...) Best regards, Brian On Apr 9, 2012, at 9:07 PM, [email protected] wrote: > Greetings, all, > > I've had a look at draft-johnson-ipfix-mib-variable-export, and as I noted at the meeting in Paris, have a concern about the mechanism presented in section 5.3.x for adding extended field specifiers to IPFIX. I'd like to suggest a generalization of this approach. > > Supporting the description of fields in an IPFIX Record as MIB Objects is a special case of extending the Information Element space in general. I see two other _particular_ applications for this: the ability to flag or index IEs within a template (to note reverse counters, indexes, pre/post or other packet handling notation, and so on), and the ability to add type restrictions to Structured Data containers (in order to maintain template-level type information for templates containing structured data). > > However, completely defining these mechanisms is clearly out of scope for the mibvar draft (and would delay it unnecessarily), so I'd like to tweak the mechanism presented there such that it could be extended in the future. > > The basic mechanism I'm proposing is: > > 1. the creation of an general Extended Template Set (Set ID 4) and an Extended Options Template Set (Set ID 5). > > 2. Extended Template Sets contain Templates with a Template Record Header identical to those in Template Sets (Set ID 2); Extended Options Template Sets contain Templates with a Template Record Header identical to those in Options Template Sets (Set ID 3). > > 3. Both contain Extended Field Specifiers, which for IANA Information Elements appear as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Information Element ident. | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M| IE Ext. ID | IE Ext. Len. | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | Extension Content (defined by ID/Length) | > ... ... ... > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > and for enterprise-specific Information Elements appear as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Information Element ident. | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M| IE Ext. ID | IE Ext. Len. | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | Extension Content (defined by ID/Length) | > ... ... ... > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The two-byte field after the Field Length or the Enterprise Number is an extension specifier: > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M| IE Ext. ID | IE Ext. Len. | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ^ ^ ^ > | | Extension length (2-255 bytes, including specifier) > | Extension type (as per new Template Extension Registry, see below) > More Bit (1 = more extensions after this; 0 = this is the last extension) > > 4. The creation of a Template Extension Registry, to be managed by IANA and modified by Standards Action, initially having the following two entries: > > IE Extension ID 0 = Null Extension: allows the specification of a standard IPFIX Information Element not having any extension information within an Extended Template Record. Null Extensions MAY have any length (greater than the minimum 2). Their content SHOULD be zero and MUST be ignored by the CP. This allows the maintenance of 32-bit alignment within templates if desired by the EP; a non-extended IE could then look either like: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Information Element ident. | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| ext ID = 0 | ext len = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > or: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Information Element ident. | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| ext ID = 0 | ext len = 4 | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > IE Extension ID 1 = MIB Variable Extension: allows the specification of an Information Element as a MIB Object, as follows. The Information Element Identifier is in this case _ignored_, but SHOULD be the MIB OID IE. An EP MUST NOT export a Template with a MIB OID IE field without a MIB Variable Extension attached. > > 5. The definition of the MIB Variable Extension format, which as far as I am concerned remains an open question. It's pretty clear that for non-indexed MIB objects it looks very much like just sticking the content in section 5.3.2 into the extension content: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| MIB OID IE | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| 1 (mibvar) | IE Ext. Len. | Index Count 0 | MIB OID Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MIB Object Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I'm not sure if I like the indexing mechanism specified in sections 5.3.3 through 5.3.5 yet (I'm not an SNMP guy), so I might suggest something. The question I _think_ I have an answer for but am not convinced of: is there _ever_ a case where a MIB Object element will be indexed by something _NOT_ in the enclosing template? If not, why not just have a list of template field indices as MIB object indices? seems like it would take a lot less effort at both the EP and the CP, and would lead to a lot less possibility of exporting a bad extension. i.e.: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| MIB OID IE | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| 1 (mibvar) | IE Ext. Len. | Index Count 2 | MIB OID Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MIB Object Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | field spec pos of 1st index | field spec pos of 2nd index | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Thoughts? > > Best regards, > > Brian > On Jul 6, 2012, at 11:50 PM, [email protected] wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Flow Information Export Working Group of the IETF. > > Title : Exporting MIB Variables using the IPFIX Protocol > Author(s) : Benoit Claise > Paul Aitken > Juergen Schoenwaelder > Filename : draft-ietf-ipfix-mib-variable-export-00.txt > Pages : 52 > Date : 2012-07-06 > > Abstract: > This document specifies a way to complement IPFIX Flow Records with > Management Base (MIB) objects, avoiding the need to define new IPFIX > Information Elements for existing Management Information Base objects > that are already fully specified. > > This method requires an extension to the current IPFIX protocol. New > Template Set and Options Template Sets are specified to allow the > export of Simple Network Management Protocol (SNMP) MIB Objects along > with IPFIX Information Elements. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-mib-variable-export > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPFIX mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix