Subject: [IPFIX] ipfix mib export and context information

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jun 2011 11:39:05 +0200

Hi,

as explained in section 3.3 of RFC 3411, MIB objects (identified by an
OID) always exist in a context. A context is identified by a
contextEngineID and a contextName. In colloquial terms, the
contextEngineID identifies an SNMP agent and a contextName identifies
an OID tree accessible on that agent. In short, within a management
domain, a unique name of a MIB object is the following 4-tuple:

  (contextEngineID, contextName, object-type OID, instance-identifier)
    |                        |    |                                |
    +-----------+------------+    +--------------+-----------------+
                |                                |
             context                            OID

Many agents only have one context (the so called default context) and
hence this is mostly invisible for many people. However, in certain
situations, contexts are used. The classic example are bridges that
have an instance of the BRIDGE-MIB for each VLAN (in this case the
contextName used to distinguish BRIDGE-MIB instances is usually the
VLAN name).

For exporting MIB objects in IPFIX, we need to deal with the
representation of contexts:

a) If a MIB object exists in the default context (zero length
   contextName), then the contextName is not carried in IPFIX.

b) If a MIB object exists in a non-default context, then the
   contextName needs to be carried in IPFIX. There are again two
   options:

b.1) The contextName is associated to the template. This means all MIB
     objects in an IPFIX flow record must belong to the same SNMP
     context. Continuing the example mentioned above, you would not be
     able to have flow record that carries a MIB object for multiple
     VLANs. (Note that a similar restriction exists in SNMP since a
     PDU is always scoped to one context.) The trade-off here is that
     flow records are smaller at the expense of having to deal with
     more template options in cases where many contexts are used.

b.2) The contextName is associated to a MIB object in a flow record.
     This allows to have objects existing in different SNMP contexts
     on the same "agent" to be carried in a single flow record.
     However, there is a price for this flexibility since context
     information is now repeated in every flow record.

Independent of the options a), b.1), and b.2) above, there is a
question whether the contextEngineID should be carried somewhere? This
would disambiguate things if a device has multiple SNMP agents running
concurrently. If the contextEngineID is carried, then this should
likely be part of the template information, not the flow records.

So the main question at this point (sorry for the lengthy
explanation): Should we go for b.1) or b.2) or even allow both b.1)
and b.2)?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>