Re: Chassis MIB comments

[[e-mail]]

>
>Please accept my contribution to the Chassis MIB discussion.
>
>1) I'm not quite sure why a Chassis MIB would contain 
>chasEntityAdminStatus and chasEntityOperStatus. These objects
>reflect functionality that is common to all devices, and not
>just chassis based devices. I would think that they belong in 
>the systems group of MIB II (or MIB III). 
>
>The above also seems to be in opposition to what one can read in
>the proceedings from San Diego:
>
>-->>
>The working group is chartered to define MIB objects that represent 
>the mapping of logical functions of traditional network devices onto
>particular physical hardware resources within the chassis. These MIB 
>definitions will not address any aspect of the network functions 
>comprised by a chassis box that are shared with an analogous collection
>of discrete devices.
><<--
The goal was to provide a central control over the entities defined
in a given chassis.  This would include enable and disable of the said
entity.  Much of the current feeling is that these objects are useful.
However do others agree with the above statement.

>
>As I read the Chassis MIB, there is a one-to-one relationship between 
>MIB II and chasEntityTable. One could go so far as to suggest that most 
>of the chasEntityTable belongs in the systems group of MIB II. The 
>chasEntityTable would only have to contain:
>
>                  chasEntityParty
>                  chasEntityCommunity
>                  chasEntityIpAddress
>
>in order to point to MIB II.
>

Yes, Keith and myself discussed multiple instances of MIB II on a per
entity basis.  The current thoughts are that there should be an
instance of the system group and the IF group (if not others) for
each entity defined.  However when we last discussed it Keith was
unsure how to best handle this.  One thought was to keep these fields
here as well as the system group.  Perhaps Keith can fill us in
with what he sees as the correct direction.

>2) Jason Perreault raises a good question:
>
>>   To what level of detail ought the MIB seek to represent the
>>   physical composition of the chassis?
>
>A popular thing among todays management stations is to show a
>photographic correct drawing of the chassis. One could require
>that the Chassis MIB be detailed enough to let a MS create such
>a picture. If this is the case the MIB should contain information 
>about contents of LCD displays, key pads, LED's, fans, connectors, etc. 
>
>These items constitute "physical hardware resources within the chassis",
>even though one can argue if there is a "mapping of logical functions 
>of traditional network devices" onto these resources.
>
>Maybe such objects should be in the PSU MIB, or in an environment MIB ?.
>
I maintain that much of the above information is very vendor specific.
Fans and power supplies could be include in this MIB.  One could also
argue that a seperate MIB maybe more useful.

>3) I share the concern raised by others about the possibilty to disable,
>enable and change segments on the fly, by means of the chasConfigTable.
>I.e changing the segment might move a device from one side of a router
>to the other, making the IP address invalid. It may also disconnect
>the agent from the MS all together, disallowing further management.
>
>At the same time I realize that there is a need for doing such
>configuration. Maybe we need a mechanism that allows for changing 
>segment and IP address in one go. When such a set has been initiated,
>the entity/device could wake up on a different segment, with a new
>identity,

We here at Cabletron use the chasEntityAdminStatus to perform this
function.  The chasEntityArgument is passed to the entity when
initialized.  Then the entity is in complete control over what segments
it is active on.  It allows the same functionality but it puts the
entity in complete control.

I could also argue that having this table read/write violates our charter
because we change the nature of the network.

How many complaints will
I get if I change these objects to read-only?

>
>4) I like the idea of a chassisUptime. This solves the problem that
>2 agents residing in the same chassis report different values of
>chasSlotLastChange for the same slot. In general I think it would
>be a good idea to state that all agents in the same enclosure shold
>provide the same view of the chassis. I could easily imagine that 2 
>agents would report different values for chasPhysicalChanges.
>

If there are no complaints I will add these objects for the next
draft.

>5) I like chasConfigIfIndex. For a device with 2 interfaces there
>is currently no way of knowing which physical interface they map onto.

However how much use is it if we have multiple instances of the interface
group of MIB II?

>
>6) Would it make sense to have chasSegmentType take on the same
>set of values as IfType in MIB II ?. 
>
>7) When an entity has more than one IP address (router etc.), how
>does it make them fit into the chasEntityIpAddress ? 
>
Perhaps the best answer for points 6 and 7 is to see how we can
account for multiple instances of MIB II.  Much of this may fall
out at that time.

/David Arneson