Re: if mapping

[dsiinc![e-mail]]

>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.
[e-mail]			531 W. Roosevelt Road, Suite 2
708-665-4639			Wheaton, IL 60187-5057