if mapping

ricci@mtunm.att.com Thu, 18 February 1993 20:26 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14392; 18 Feb 93 15:26 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14388; 18 Feb 93 15:26 EST
Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa04950; 18 Feb 93 15:26 EST
Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA22651; Thu, 18 Feb 93 14:58:40 -0500
X-Resent-To: fddi-mib@CS.UTK.EDU ; Thu, 18 Feb 1993 14:58:39 EST
Errors-To: owner-fddi-mib@CS.UTK.EDU
Received: from att-out.att.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA22641; Thu, 18 Feb 93 14:58:31 -0500
Message-Id: <9302181958.AA22641@CS.UTK.EDU>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: ricci@mtunm.att.com
Date: Thu, 18 Feb 93 14:54 EST
Original-From: ricci@mtunm.lincroftnj.ncr.com
To: fddi-mib@cs.utk.edu
Cc: mtunm!ricci@gatech.edu
Subject: if mapping

  As I read the recent exhanges on MAC indexing, I noticed that an
restriction has been placed on the numbering of the indices for all
resources.  In particular, indices are restrictied to 1-N "to ensure a
1-to-1 mapping between SMT resource Id's and SNMP indices."  In other words,
this restriction is supposed to help insure that, given a particular
resource, its SMT index is the same as its SNMP index.
  This restriction, however, cannot guarantee that such a 1-to-1 mapping can
be created and, in fact, will cause some FDDI implementations to be
unrepresentable.  Why?  Because the SMT spec neither suggests or requires
that an implementation use a sequential numbering scheme for resources.  You
could, for instance, have three MAC resources and assign them the indices
100, 1, and 50 - it's all implementation dependent.  If such an assignment
were made you wouldn't be able to represent the device and its resources
using the current MIB (with its restriction).
  Off the top of my head I can think of two ways to remedy this situation.
One would be to simply remove the restriction of 1-N -- do this and the
problem goes away.  SNMP can handle "holes" anyway thanks to getnext.
The other option would be to maintain a 1-N numbering but drop the bit about
creating a 1-to-1 mapping.  In fact, in this case you would probably want to
add yet another variable to each resource that contained its actual SMT index
(in the case of the MAC that would be ANOTHER additional variable above the
one to tie the MAC to an interface).  I think I prefer the first method but
I'm sure others will have comments.
  One last point - this about ghosts.  Given a ghost resource, in SNMP it
seems improper to be able to retreive some variables and skip others that
have "gone away" because of ghosthood.  It also appears to be improper to
assign "default" values to these shadow variables - although I think a good
case could be made for this type of operation.  The most "correct" method,
however, also appears to be the simplest and cleanest and involves
seperating out such shadow variables into seperate tables - a method Ron
Mackey from DSI wrote about some time ago.  I'd like to endorse that method
and see it end up in the MIB.  If I remember correctly Ron has already
seperated the variables so all we need do is put them into tables -  perhaps
Ron or someone else could supply the text??


   Sal Ricci
   AT&T/NCR Network Products Division