Subject: [IPFIX] draft-johnson-ipfix-mib-variable-export and template extension

From: Brian Trammell <[email-masked]>
Date: Mon, 9 Apr 2012 21:07:39 +0200

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