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 1993 14:54:00 -0500
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?? Regards, Sal Ricci AT&T/NCR Network Products Division
- 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