Re: Entity Management and Dual IP Stack

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