RE: WG ACTION: Chassis MIB (chassis) to

[{3COM/PDD/PeteW}@pdd.3mail.3com.com]

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To:  Chassis MIB
Subject:  RE: WG ACTION: Chassis MIB (chassis) to conc
Date: 1993-07-21 16:46
Priority: 
Message ID: C3346EA0
Conversation ID: C3346EA0

------------------------------------------------------------------------------

Some more thoughts...

Before we get any further it would be very useful to come to some agreement 
about what we are and what we are not going to try to solve. That is what 
are our requirements of the MIB. If we have to start a new working group 
then we get to rewrite the charter. We can rule out managing the state of 
Texas once and for all!

Here are a few initial thoughts:

1) Represent a 'physical' inventory of a network multi-service chassis type 
device. ie a real network chassis, not some arbitrarily complex container! 
The physical configuration of the chassis is represented by 'modules' which 
reside in 'module locations'.

2) Represent a 'logical' inventory of entities in the chassis. An enity 
being a 'logical device' within the chassis. You get these by imagining the 
function of the chassis configuration without the chassis, that is in terms 
of discrete devices. The logical configuration information identifies the 
means of identifying an agent (through addressing information) that provides 
specific MIBs for that entity.

3) To provide a mapping of parts of physical modules to logical entities. 
The mapping will be by means of a resource. A resource is a 'component' of a 
module.

4) To allow the flexible reallocation of resources between different 
entities in the chassis. Without this the main benefit of the chassis is 
lost, that of flexibility!

5) To provide an optional MIB group that provides topology information 
describing the interconnection of the logical devices within the chassis. 
For example, Router port A connects to Ethernet segment X. Note that keeping 
this seperate makes both the agent and the management application simpler. 
The problem is broken down into smaller, more manageable chunks.

6) To provide a MIB that can be used to implement a generic chassis 
management application.

Note that PSUs, sensors etc are outside the scope of this MIB at the present 
time. Lets get the model correct and then worry about devices in the 
chassis. A PSU is no different to a repeater, its still an entity in the 
chassis!

Pete