Re: Mib questions

["David L. Arneson ([e-mail])" <[e-mail]>]

I'm going to try and jump in the middle on some of this.  Great timing for a
short vacation.  I miss all of the fun.
I extracted this from a conversation that David Perkins and Bob Stewart were
having.

 
> >On question 9, which is
> >>>9) What are some situations the it would be appropriate to use
> >>>   a "sparse" slot table?
> >
> >You said...
> >>Any situation the implementor chooses.  You might choose to do that in a
> >>2-slot chassis or one the size of Texas.
> >
> >What would be a situation where an implementor would choose?  It there are no
> >criteria, then I would suggest in the name of interoperability that the MIB
> >choose one model.
> 
> In a small system where the chassis is in fact a well defined hardware crate,
> I'd probably expect to see a filled-in slot table, but not necessarily.  In a
> large, amorphous chassis, I'd expect a sparse table, to save overhead.  To me
> this falls in the same general category as deleting an entry with 'invalid'
> status.  Why not just leave it up to the implementor?
> 
The main reason that the slot table maybe sparse is due to the space that
may be taken up maintaining all the object associated with a slot that is
currently vacant.  If you have limited resources then perhaps the sparse
table is best for you.  However a dense slot table has some advantages as
pointed out by Keith in a later message.


> >I was asking another, more fundamental question, that is - what really
> >is a logical device?  Is a module that has a general purpose CPU
> >on it (i.e., a "host") count as THE "logical device", or can it be
> >further divied so that applications running on it count as
> >"logical devices". (BTW - this sort of feel like the interfaces model
> >question.) 
> 
> Hmmmm.  I see.  MUST you divide up into separate entities?  I guess not, since
> type is a bitmap, unless, as with a repeater, other definitions say you must.
>
The model I have been following is that an entity would have a single task
in life (bridge, router).  Keith however belives that an entity may have
multiple jobs.  I'm still not sure why he says this but I can live with
it.

Now the definition of logical device.  This is a bit of a tough one.  You may
choose to divide your host up so that the applications are seperate
entities.
 
> >On the last question that I had, which asked how was an agent that implemented
> >the chassis MIB to get the values for the MIB objects, you indicated
> >that the "most sensible" choice was to use a backplane bus. There are
> >two followups here.
> >
> >1) Is it OK to use a VERY simple backplane bus that can give only limited
> >   information such as the IDs of the physical modules and which slots
> >   have modules installed, then use configuration files for the other
> >   information such as IP address?
> >2) How many real live implementations are there out there that have the
> >   backplane and CPU support to implement the complete set of objects
> >   without use of configuration files? (We have got to ask this question.
> >   If people want the responses to be confidential, then Bob or Jeff or
> >   someone needs to summarize the responses.)
> 
> On part 1, what you suggest seems acceptable, but maintaining such files
> correctly would be a pain.  But then who am I to judge?  Part 2 is the
> question I've kept asking and not seen any answers.  If people want to make
> confidential answers, I suggest they make them to Jeff, as chassis-type
> products are part of Xyplex's business.
>
1) I don't see anything wrong with the above.  You may choose to save
the information in NVRAM, file what ever.  The only thing that I feel is
important is that the information returns unchanged after reset.

2) We here at Cabletron have a chassis MIB implemented in our latest
modules.  This MIB is what was proposed by Manu Kaycee at the San Diego
IETF.  The two are quite close.  We use NVRAM to save the information
required.  If I remember correctly we use about 3K bytes to save all
the information that may change (entities maintain the other information).
We also have one chassis MIB in each chassis.  We already had most of
the information available to us.
 
> 	Bob