Re: [IPFIX] ipfix mib export and context information
Benoit Claise <bclaise <at> cisco.com>
2011-07-07 10:29:15 GMT
Let me ask the question differently.
Do you see a use case for the export, within a single flow record, of
MIB variables from different SNMP contexts?
> 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
> 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)?
IPFIX mailing list
IPFIX <at> ietf.org