Re: if mapping

Anil Rijsinghani <> Wed, 17 February 1993 23:12 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa22113; 17 Feb 93 18:12 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22109; 17 Feb 93 18:12 EST
Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa08125; 17 Feb 93 18:12 EST
Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA26986; Wed, 17 Feb 93 17:46:12 -0500
X-Resent-To: fddi-mib@CS.UTK.EDU ; Wed, 17 Feb 1993 17:46:10 EST
Errors-To: owner-fddi-mib@CS.UTK.EDU
Received: from by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA26969; Wed, 17 Feb 93 17:46:07 -0500
Received: by; id AA11609; Wed, 17 Feb 93 14:46:03 -0800
Received: by; id AA17761; Wed, 17 Feb 93 17:43:40 -0500
Message-Id: <>
Received: from levers.enet; by us1rmc.enet; Wed, 17 Feb 93 17:43:43 EST
Date: Wed, 17 Feb 93 17:43:43 EST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Anil Rijsinghani <>
To: dsiinc!
Apparently-To:, dsiinc!
Subject: Re: if mapping


> 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.)

    ifSpecific points you at the root OID of the particular interface
    MIB that is appropriate for this media type; however it does
    not tell you which particular ifIndex is associated with
    the MAC.  This information is needed for applications which
    want to present information derived from multiple MIBs relevant
    to an interface.

> 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.

    In RFC-1285, the description of snmpFddiMACIndex specified that
    the value of MACIndex is the same as the corresponding ifIndex,
    however the current draft says only that it uniquely identifies
    the MAC.

    Given last meeting's decision to use SMT resource id's, a new
    MACifIndex object seems the way to go.

> 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.

    The Ethernet Repeater MIB does not (for example) put restrictions
    on group numbering -- a group may be a card in a multi-card repeater --
    nor does it specify the actual number of groups in a repeater.
    (which can of course be found with multiple get-next's, if necessary.)
    This eliminates the dilemma encountered with MIB-II where the total
    number of interfaces is specified in the interface group, and the
    description of ifIndex says that it must be 1..ifNumber.  Some
    vendors get around this by ignoring the restriction in order to allow
    applications which were monitoring interfaces to work correctly,
    others renumber interfaces.