Re: Mib questions

[[e-mail] (Keith McCloghrie)]

Bob,

> Dave,
> 
> Nice "private" conversation we're having here.  I guess everybody else must
> agree with me.  

Well, surprising or not, I do just about agree with all your answers to 
Dave's questions.
 
>>When multiple agents in a chassis implement the MIB...
>>6) Must the value of ... be the same for both?
 
> I would expect the values to mostly be the same.  It is after all supposed to
> be the same chassis.  Values based on sysUpTime would be relative to the
> individual agent.  So what does it mean if an NMS finds inconsistent values?
> Uhhh, got me.  Depends on how you use them.  In the Interface Table thread,
> Keith said we have to include segment mapping in the Chassis MIB because we
> need a single, consistent way to number segments.  I guess I'd expect that
> sort of assertion to be desirable, if not required, across everything in the
> chassis.  They are supposed to be tied together in SOME way after all.
 
I would say it stronger, i.e., if the same chassis is being managed 
by two different agents, then the intent is that there is one set of 
information which is the same, whichever agent you get it from.

However, I don't understand why you would have multiple agents in a 
chassis implementing the chassis MIB.  A chassis is an entity to be 
managed just like a workstation (which might have several intelligent 
cards plugged into its slots with agents on those cards?).  Why would 
you have two agents in the workstation implement the workstation MIB ??

There's only one scenario I can think of, and that's nesting.  For example,
if you applied the Chassis MIB to an equipment rack containing several 
shelfs, and you applied the Chassis MIB to each shelf with its card slots, 
So, you get a nesting of Chassis MIBs, where the Chassis MIB of each shelf 
is a "logical device" in the rack's Chassis MIB.

> 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?
 
I agree.  We have faced this situation with the ifTable, and with the
Repeater MIB's rptrPortTable.  In situations where there's one or two
unused/not-present conceptual rows, it's better to have a dense table.
In situations where there might be tens (or hundreds) of not-present
conceptual rows, it's better to have a sparse table.

> >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.
 
Right, a "logical device" corresponds to a MIB view.  If you multiplex
by SNMP parties, then each party has a separate MIB view, and is thus
a separate logical device.  If the MIBs of two functions can co-exist
in the same MIB view (e.g, a bridge and a router) then one logical device
can have both functions.

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

Note that if the agent for a logical device is accessed via an SNMP party,
then there is no IP address for it in this MIB.  

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

I thought I'd seen some responses which said they could.  I guess we'll
have to ask Jeff.

Keith.