Subject: RE: [Entmib] Entity Management and Dual IP Stack

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 27 Oct 2005 12:01:26 -0600

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 

Eduardo

-----Original Message-----
From: Sharon Chisholm [mailto:[email-masked]] 
Sent: Thursday, October 27, 2005 10:26 AM
To: Entmib-wg (E-mail)
Subject: RE: [Entmib] Entity Management and Dual IP Stack

hi

Are you saying it has two IP addresses, or supports both Ipv4/IPv6 or
that it is two logical devices (virtual router, etc)? In the first two
cases you only have one logical devices from the Entity MIB's
perspective.

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eduardo Cardona
Sent: Thursday, October 20, 2005 10:37 AM
To: Entmib-wg (E-mail)
Subject: [Entmib] Entity Management and Dual IP Stack

I have a question, 

For an entity with 2+ logical entities (implements entLogicalTable) How
do you define the logical entity if the device has dual stack and is
manageable using both IPs ? 
Shall it defines a duplicate logical entity for the second
entLogicalTAddress? 

I mean, in the interest of reflecting entLogicalTable entries? Or is
left vendor dependent? 

Thanks

Eduardo

_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Oct 2005 00:55:06 +0200

> entLogicalTAddress to support both IPv4 and IPv6 for the same logical

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

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 28 Oct 2005 12:47:24 -0700 (PDT)

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.

> report" (where?) so that people can worry about this once this MIB is

Regards,
/david t. perkins