Re: Dense?

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

> 
> On the Dense vs Sparse questions, the replies still
> leave me a little confused. So, "here I go again."
> 
> Here is a simple senario: Vendor XXX has a chassis
> that has eight slots for boards.  There is no CPU
> (i.e., agent) in the chassis, which is really just
> a cardcage. The types of cards that vendor XXX
> manufactures are the following: 1) power supply
> (which has no CPU or agent), 2) router,
> 3) ethernet repeater, 4) terminal server,
> 5) "host", 6) FDDI concentrator, and 7) bridge.
> No card does more than one "function" and the
> complete function is totally done on one card.
> (In this simple example, the router is not implemented
> to take up two slots, for example.)
> 
> All slots are identical so that any card can be
> inserted in any slot.
> 
> Now, consider the following configuration:
>   slot   status
>   1-3    empty
>    4     power supply
>    5     empty
>    6     router
>    7     empty
>    8     terminal server
> 
> If an agent (in either the terminal server or the
> router) implements the chassis MIB, if
> the entries in the slot table are numbered
> 1 to 8 so that they correspond to the physical
> slots is this dense or sparse?
> 
> I would say this would be "dense". If the entries
> in the slot table were numbered 2 (slot 1), 4 (slot 2),
> 8 (slot 3), 16 (slot 4), 32 (slot 5), 64 (slot 6),
> 128 (slot 7), and 256 (slot 8), then I would say these
> would be "sparse". However, I don't understand what
> situations that this numbering would be appropriate?
> And again, would it be Ok for the router that implemented
> the chassis MIB to use the first numbering, and the
> terminal server that also implemented the chassis
> MIB to use the second numbering?
>
What we are trying to say is that if the slot table has entries for slots
1 thru 8 with 1 - 3, 5, and 7 identified as empty slots then the table
is dense.  We agree there.

Now sparse would not have entries for 1 - 3, 5, and 7.  It would only have
entries for 4, 6, 8.

Now I don't see any reason why you couldn't define chasSlotIndex any way
you wanted.  However it seems natural to me that you would want to define
the index to correspond to your slot numbers.

Now once again it should appear that there is only 1 instance of the chassis
MIB.  So if you have a chassis MIB on both the router and terminal server
they must provide identical information. This includes times, indexes etc.
Keith takes a somewhat stronger stance in saying that there must be only
one chassis MIB in a given chassis.  I belive that some implementations may
find it useful to maintain redundent copies of the MIB.  The key term is
redundent.  The information must be the same for all copies present in the
chassis.
 
> Also note that the power supply is a "dumb"
> "logical device" that doesn't have an agent
> and doesn't have a MIB (yet).  How does it
> fit into the chassis MIB model?
>
I think what we need to understand is that an entity may provide you a MIB
view.  This MIB view is addressable either by IP address and community string,
or party.  However there is nothing stated that it must provide a MIB view.
For power supply we seem to be directed towards putting this as a group of
the chassis MIB.  Therfore we would once again see one copy of this addressable
in the chassis MIB.

All we are doing is telling the outside world that there is a power supply
present in the given slot.  Since we provide no address information there are
no MIBs to be viewed.

Does this answer your question?
 
> Finally, is this simple example a "good" one to
> use for further discussion?  What other additional
> information needs to be added (maybe information
> about backplane(s))?
>
It would seem that this is a good start for a discussion about the slot table.
However the next level would be to discuss entity connections (interfaces,
segments).  There has been alot of talk about this as of late, and we must
try to reach an agreement in the near future.
 
> Thanks,
> /dave perkins, synoptics, 408-764-1516