Re: [Entmib] Entity Management and Dual IP Stack

"David T. Perkins" <dperkins@dsperkins.com> Fri, 28 October 2005 19:47 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVaCa-0006aJ-AI; Fri, 28 Oct 2005 15:47:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVaCX-0006ZY-SW for entmib@megatron.ietf.org; Fri, 28 Oct 2005 15:47:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05053 for <entmib@ietf.org>; Fri, 28 Oct 2005 15:47:27 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVaQ9-0007eq-J5 for entmib@ietf.org; Fri, 28 Oct 2005 16:01:50 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j9SJlVCO018151; Fri, 28 Oct 2005 12:47:32 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j9SJlOTr022094; Fri, 28 Oct 2005 12:47:24 -0700
Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j9SJlOhM022090; Fri, 28 Oct 2005 12:47:24 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Fri, 28 Oct 2005 12:47:24 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Eduardo Cardona <e.cardona@CableLabs.com>
Subject: Re: [Entmib] Entity Management and Dual IP Stack
In-Reply-To: <20051027225506.GA21228@boskop.local>
Message-ID: <Pine.LNX.4.10.10510281218040.14221-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: "Entmib-wg \(E-mail\)" <entmib@ietf.org>
X-BeenThere: entmib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Entity MIB WG <entmib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:entmib@ietf.org>
List-Help: <mailto:entmib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=subscribe>
Sender: entmib-bounces@ietf.org
Errors-To: entmib-bounces@ietf.org

HI,

In addition, the original motivations for the logical entity table
was to "solve" two problems:
  1) In a chassis that contained multiple cards (which may be
      called "blades" or "service packs", etc) where each is
      really a separate network function (such as a router,
      an bridge(switch), etc). The logical entity table was
      suppose to provide a list of "other network devices"
      in the chassis.
  2) There were some MIB modules (primarily the Bridge MIB module)
     that were lacking a top index to support multiple instances.
     Contexts are used when such situations exist. (And in
     SNMPv1 and SNMPv2p where the context is not a direct
     field in SNMP messages, the community string value is
     used to specify (in directly) a context value.

Even though it has been pointed out numerious times over the
years the problems with the logical entity table, it appears
the only "standard" way to obtain the above information.
      

On Fri, 28 Oct 2005, Juergen Schoenwaelder wrote:

> On Thu, Oct 27, 2005 at 12:01:26PM -0600, Eduardo Cardona wrote:
> > Thanks for the reply. 
> > 
> > It is one logical entity with two IP management addresses  ( one IPv4
> > and one IPv6), my question is how to configure entLogicalTDomain and
> > entLogicalTAddress to support both IPv4 and IPv6 for the same logical
> > entitiy 
> 
> I agree that this is a valid question to ask and it seems that there
> is no good answer to this question.
> 
> My understanding of the SNMP architecture is that an SNMP engine is
> identified by an SNMP engine ID. Since an SNMP engine can be attached
> to multiple transport endpoints, there needs to be a 1:N mapping of
> SNMP engine IDs to the transports the engine is listening on. The
> SNMPv3 specs may not be particular clear how this 1:N mapping is
> represented in the core SNMP MIBs (and I believe the SNMP core MIB
> modules are the place where this information should be represented).
> 
> The ENTITY-MIB should not try to duplicate this information 1:N
> mapping and just refer to the appropriate table via the relevant SNMP
> engine ID. However, the ENTITY-MIB was first published in 1996 (RFC
> 2037) and at that time the concept of an engine ID did not really
> exist so it is understandable why the entLogicalEntry looks like it
> does.
> 
> To summarize: I see a problem here. Is it worth fixing?  Perhaps.  How
> much time will it take to do that in the IETF? I better don't
> speculate. Perhaps much more important is to record this as a "defect
> report" (where?) so that people can worry about this once this MIB is
> opened up for revision.
> 
> /js

Regards,
/david t. perkins


_______________________________________________
Entmib mailing list
Entmib@ietf.org
https://www1.ietf.org/mailman/listinfo/entmib