Re: Chassis MIB comments

[Kiho Yum <[e-mail]>]

Hi all,

Just thought I'd throw my two cents in.

Overall, I agree with many of Dave's comments (I will
note where I don't agree or agree strongly).  His comments 
also expose some issues in the chasConfigTable which I will 
try to expand on.


/kiho


> 
> Following is a long list of comments on the chassis MIB.
>----------------------------------------------------------
> Notes on Chassis MIB, October 13 version.
>    dtp - 10/13/92, 10/15/92
> 
> 
> 6) The example needs to be made more comprehensive. Consider
> the follow revision:
> 
>   5.1.  Example Chassis
> 
>   Consider a simple 8 slot chassis that contains a bridge,
>   2 repeaters, a terminal server, router, and a power supply.
>   The chassis is organized as follows:
> 
>     Slot  Entity  Segment  Device
>       1     2        1     Bridge - one slot, two connections
>       1     2        2
>       3     1        1     Repeater - two slots, two connections
>       4     1        1
>       5     3        2     Repeater - one half a slot, one connection
>       5     4        1     Terminal server - one half a slot, one conn
>       6     5        1     Router - two slots, two connections on first
>       6     5        2              slot and none on second slot
>       7     5        0     
>       8     6        0     Power supply - one slot, no connections   
> 

This example shows one of the "problems" with the index of this
table.  Since it uses {Slot, Entity, Segment} as its index,
no entity can have more than one connection to any one segment,
unless that entity happens to span two or more slots.  

Dave shows a repeater with two connections to the same segment
(luckily it spans two slots, allowing him to show the entry
in this table).  Surely there must be other examples of a single
function entity requiring multiple connections to the same segment.
(multi-function entities that have multiple connections to the
same segment can be split into single function entities).

How about adding chasConfigIndexType (and chasConfigIndexValue,
although I too don't see why we need both objects) to the
INDEX clause?



> 8) Section 5.2 needs to be renumbered and cleaned up something
> like the following:
> 
>   5.3.  The Entity Table
> 
>   The entity table contains information about the entities in
>   a chassis.  In addition it defines the means to access a MIB
>   view for each such entity, if access is possible.  These may
>   be addressed either by the combination of chasEntityCommunity
>   and chasEntityIPAddress or by chasEntityParty.
> 
>   Using the above example the entity table will have 6
>   conceptual rows, one for each entity. In the example
>   the entities are 2 repeaters, a bridge, a terminal server,
>   a router, and a power supply.
> 
>   Implementation of the entity table is optional.
> 

Why make this table optional?  I think the party and addressing
information in this table is very important and should be made 
available.



> 10) Section 5.4 needs to be renumbered and cleaned up something
> like the following:
> 
>   5.5.  The Chassis Configuration Table
> 
>   The chassis configuration table contains the mapping of
>   entities to segments.
> 
>   The objects, chasConfigIndexType and chasConfigIndexValue
>   provide linkage from an entity's segment connection in this
>   MIB to the management information contained in the entity's
>   own MIB.  In particular, these objects indicate that the
>   particular segment connection of the entity in the slot
>   represented by this conceptual row is identified within the
>   entity's MIB by the object type named by chasConfigIndexType
>   having the value given by chasConfigIndexValue.
> 
>   It is an implementation specific matter whether the
>   chasConfigTable is implemented to allow creation and/or
>   deletion of conceptual rows.
> 
>   Using the above example the configuration table would contain
>   10 conceptual rows.  One for each slot, entity, segment
>   combination defined in the example above.  The first
>   conceptual row would define the bridge entity in slot 1 with
>   chasConfigIndexType of bridge port and chasConfigIndex value
>   of 1.  The other conceptual rows would be similar defining the
>   bridge port and repeater ports.
> 
>   Implemenation of this group is optional.
> 

Again, why make this optional?  



> 11) A new section needs to be added to describe the
> chassis description objects. An example would be the
> following:
> 
>   5.6.  Chassis Description
> 
>   The chassis description group contains information about
>   the physical chassis.
> 
>   Implementation of this group is mandatory.
> 

Sounds like a reasonable idea.  Kind of like sysDescr, except for the
chassis.  (remember, if one of the entities implemented this MIB,
sysDescr would describe that entity and not the chassis).

I would make this optional, though :^)


> 
> 11) Section 5.5 needs much work to be complete. The 
> approach about virtualizing a physical chassis into
> a logical chassis seems interesting. However, the model
> and values for the MIB objects do not seem to support it.
> Several concrete examples need to be given. One needs to
> show a hierachical organization of several layers and
> the values of the objects at each layer. What do
> segments map into with a virtual chassis? What are
> the values for the following objects when a multi-level
> virtual chassis is used: chasSlotModuleType,
> chasSlotLastChange, chasSlotModuleVersion,
> chasSlotModuleSerialNumber, chasEntityFunction,
> chasEntityFunction, chasEntityObjectId,
> chasEntityVersion, chasEntityAdminStatus, 
> and chasEntityOperStatus? 
> 

I agree with Dave.  I like the idea of hierarchical chassis
and the application of this MIB to things other than boxes.
At the same time, however, allowing that much generality scares 
me.  There are a lot of creative people out there, and they could
interpret this MIB in a lot of different ways.  We should be
careful.  Examples would certainly help.



> 
> 21) The Party, Community, and IpAddress should be split
> from the Entity table into a parallel table. This information
> may not be available even if the other columns in the
> table are. There are several chassis implementations where
> 

I would support this if we made the parallel table 
mandatory (although, I would add chasEntityObjectID to
the parallel table as well).  Looking at the current 
chasEntityTable, several of the columns are available from mibII 
objects within those entities' MIB views, so making this modified
table optional seems reasonable to me.

As a side note, is the IpAddress only to be used for community
SNMP, or can party-based SNMPv2 requests be sent to that
address?  If not, why not?


> 23) For the object chasEntityFunction, what is the meaning
> of the value "services"?
> 
> 24) The object chasEntityFunction should have a value
> which means "host".
> 
> 25) The list of functions for chasEntityFunction seems too
> short. What other functions exist in current chassis?

We have to be careful about defining too many types of functions
without really thinking about them.  Even a little ambiguity is a 
bad thing for this object.


>  
> 26) The column chasEntityObjectId seems useless. It identifies
> an agent, not an entity, and for those entities like power
> supplies, there may be no agent that has information about
> them.

Yes, but for those entities that do have an agent, it provides
a quick and easy means for a mangement station to identify the
(functional) entities the chassis supports.


> 30) The object chasEntityArgument seems very implementation
> specific. It should be tossed.

I agree with Dave that we should not include any obvious implementation
specific objects here.  Is there a precedent for this issue?


> 37) The object chasConfigIndexType (and chasConfigIndexValue)
> have ambiguous values. (For example, consider a brouter
> (router/bridge). A connection could be a bridge port and
> an interface. Which should be used?) As such, they should
> be removed since they are misleading (or rules must be
> defined to help in choosing the value). 

If you are talking about an entities' bridge port and its router port
connected to the same segment, that multi-functional entity should be 
split into a bridge entity and a router entity.

> and it should point to an instance, and not an object type.
> The object chasConfigIndexValue is not needed at all.

I agree.  We already have too many objects.