[IPFIX] ipfix mib export and context information

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 30 June 2011 09:39 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A537021F87B7 for <ipfix@ietfa.amsl.com>; Thu, 30 Jun 2011 02:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level:
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfMG4Z7Y1Pl9 for <ipfix@ietfa.amsl.com>; Thu, 30 Jun 2011 02:39:08 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8365621F87DB for <ipfix@ietf.org>; Thu, 30 Jun 2011 02:39:07 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB85F20BF4 for <ipfix@ietf.org>; Thu, 30 Jun 2011 11:39:06 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RdHzQ0UMfQtM; Thu, 30 Jun 2011 11:39:05 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D51220BD4; Thu, 30 Jun 2011 11:39:05 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 15892197B186; Thu, 30 Jun 2011 11:39:05 +0200 (CEST)
Date: Thu, 30 Jun 2011 11:39:05 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: ipfix@ietf.org
Message-ID: <20110630093904.GB3317@elstar.local>
Mail-Followup-To: ipfix@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [IPFIX] ipfix mib export and context information
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2011 09:39:08 -0000

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