Re: if mapping
dsiinc!rem@uunet.uu.net Thu, 18 February 1993 04:07 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24525; 17 Feb 93 23:07 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24521; 17 Feb 93 23:07 EST
Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa21490; 17 Feb 93 23:07 EST
Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA08129; Wed, 17 Feb 93 22:37:27 -0500
X-Resent-To: fddi-mib@CS.UTK.EDU ; Wed, 17 Feb 1993 22:37:26 EST
Errors-To: owner-fddi-mib@CS.UTK.EDU
Received: from relay1.UU.NET by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA08121; Wed, 17 Feb 93 22:37:25 -0500
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA21112; Wed, 17 Feb 93 22:37:23 -0500
Date: Wed, 17 Feb 1993 22:37:23 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: dsiinc!rem@uunet.uu.net
Message-Id: <9302180337.AA21112@relay1.UU.NET>
Received: from dsiinc.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 223655.17946; Wed, 17 Feb 1993 22:36:55 EST
To: uunet!cs.utk.edu!fddi-mib@uunet.uu.net
Subject: Re: if mapping
Content-Type: text
Content-Length: 2753
>Anil Rijsinghani <uunet!levers.enet.dec.com!anil> writes: > There currently appears to be no easy way to map an FDDI MAC to > a MIB-II interface. (Note that snmpFddiMACIndex is not defined > to serve this purpose.) I believe the MAC group needs to indicate > this mapping -- either by tuning the definition of this object, or > adding a new one. Are you suggesting that we add an entry to the MAC table containing the value of the MACs "ifIndex" in the MIB-II interface group? I'm assuming that "ifSpecific" will provide the necessary mapping between MIB-II and the FDDI MIB. ("ifSpecific" only applies to MIB-II since it didn't exist in MIB-I.) I don't see a problem adding a new variable, but I'd prefer not to change the existing MACindex. Also, I think it's definition should include the value 0, to indicate that there is no MIB-II ifIndex available. This is necessary since not all FDDI MACs may show up in the interface table. An isolated FDDI MAC (or one on a local path) may not want to advertise an external interface, as it may be there doing station testing, or as a hot backup backup for another MAC. > Also, the values of indices probably shouldn't be restricted to > 1..*number, to eliminate problems for resources which can come and > go dynamically. The reason for the restriction of the MAC (and other) indices to 1-N was to ensure a 1-to-1 mapping between SMT resource Ids and SNMP indices (and to allow use of dense tables for implementation). It also makes interpreting SNMP results easier if there is a 1-to-1 mapping between resource Ids and allows a clean understanding of the resource id information returned in the path configuration table. Of course, this 1-to-1 mapping between SMT and SNMP resource ids breaks down if you have multiple SMT instances manipulated by a single SNMP agent. I assumed this means that for ghost resources, N must always include all possible resources that may come and go. In fact, I believe it must be this way since even ghost resources have variables that are mandatory and should always be accessible even when the ghost resources are not present (like MACHardwarePresent which needs to be present regardless of the availability of the MAC). This is implied by the definition of MACNumber, which states that N must be constant until the next management entity initialization. I'd still like to know how the ghost resource problem is handled in other MIBs. I can't believe this is the first time the problem has surfaced, as there are many Ethernet hub products that allow hot-swapping of boards. Ron Mackey Distributed Systems International, Inc. rem@dsiinc.com 531 W. Roosevelt Road, Suite 2 708-665-4639 Wheaton, IL 60187-5057
- if mapping Anil Rijsinghani
- Re: if mapping dsiinc!rem
- Re: if mapping Anil Rijsinghani
- Re: if mapping dsiinc!rem
- Re: if mapping dsiinc!rem
- if mapping ricci
- Re: if mapping Anil Rijsinghani
- Re: if mapping CASE
- Re: if mapping Jason Perreault
- Re: if mapping dsiinc!rem