RE: WG ACTION: Chassis MIB (chassis) to
{3COM/PDD/PeteW}@pdd.3mail.3com.com Wed, 21 July 1993 16:21 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05688;
21 Jul 93 12:21 EDT
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa05684;
21 Jul 93 12:21 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK)
id AA05788; Wed, 21 Jul 93 11:54:56 -0400
X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 21 Jul 1993 11:54:55 EDT
Errors-To: owner-chassismib@CS.UTK.EDU
Received: from gatekeeper.3Com.COM by CS.UTK.EDU with SMTP
(5.61+IDA+UTK-930125/2.8s-UTK)
id AA05778; Wed, 21 Jul 93 11:54:51 -0400
Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA13922
(5.65c/IDA-1.4.4-910725 for <chassismib@cs.utk.edu>);
Wed, 21 Jul 1993 08:54:43 -0700
Received: by gw.3Com.COM id AA16132
(5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Wed, 21 Jul 1993 08:54:41 -0700
Date: Wed, 21 Jul 93 16:53 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: {3COM/PDD/PeteW}@pdd.3mail.3com.com
Subject: RE: WG ACTION: Chassis MIB (chassis) to
To: chassismib@cs.utk.edu
Message-Id: <930721.085509@3Mail.3Com.COM>
Msg-Date: 1993-07-21
Msg-Time: 16:51
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
- RE: WG ACTION: Chassis MIB (chassis) to {3COM/PDD/PeteW}
- RE: WG ACTION: Chassis MIB (chassis) to {3COM/PDD/PeteW}