Re: New overview text in Chassis MIB
"James R. (Chuck) Davin" <davin@bellcore.com> Mon, 12 October 1992 21:32 UTC
Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA03025; Mon, 12 Oct 92 17:32:36 -0400
Received: from thumper.bellcore.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA03021; Mon, 12 Oct 92 17:32:33 -0400
Received: from localhost.bellcore.com by thumper.bellcore.com (4.1/4.7) id <AA10686> for chassismib@cs.utk.edu; Mon, 12 Oct 92 17:32:27 EDT
Message-Id: <9210122132.AA10686@thumper.bellcore.com>
From: "James R. (Chuck) Davin" <davin@bellcore.com>
To: kzm@hls.com
Cc: chassismib@cs.utk.edu
Subject: Re: New overview text in Chassis MIB
In-Reply-To: Your message of Sun, 11 Oct 92 17:03:53 -0700. <9210120003.AA27438@nms.netman>
Date: Mon, 12 Oct 1992 17:32:26 -0400
Sender: davin@thumper.bellcore.com
Keith, I understand and agree with 5.5 below. I don't understand what 5.6 below means. Does it mean that, in a particular chassis, I may have multiple agents that export the same instances of chassis MIB objects? How/why would one implement this arrangement? Is it viable/useful for a chassis as big as Texas? If I am a management station, is this replication of the chassis information at multiple agents helpful? Confusing? How would I sort it out? Seeking enlightenment, Chuck > Replied: Mon, 12 Oct 92 17:20:37 -0400 > Replied: "kzm@hls.com (Keith McCloghrie) " > X-Folder-Dispatch: Mon, 12 Oct 92 10:55:19 -0400 > X-Folder-Dispatch: +dst-me > Return-Path: kzm@hls.com > Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) > id <AA06190> for davin; Sun, 11 Oct 92 20:08:05 EDT > Received: from nms.netman (nms.hls.com) by lanslide.hls.com (4.1/SMI-4.0) > id AA11013; Sun, 11 Oct 92 17:08:18 PDT > Received: by nms.netman (4.1/SMI-4.1) > id AA27438; Sun, 11 Oct 92 17:03:53 PDT > From: kzm@hls.com (Keith McCloghrie) > Message-Id: <9210120003.AA27438@nms.netman> > Subject: New overview text in Chassis MIB > To: chassismib@cs.utk.edu > Date: Sun, 11 Oct 92 17:03:53 PDT > Cc: davin@thumper.bellcore.com (James R. Davin) > Organization: Hughes LAN Systems > X-Mailer: ELM [version 2.2 PL0] > > > > Folks, > > I'm in the middle of generating comments on Dave's latest update > of the Chassis MIB draft. One item in particular is providing > some text that I would like to suggest be added in the Overview, > concerning the applicability of this MIB (remember the "size of Texas" > comment Jeff made in the wg's first meeting.) Another is some text > concerning multiple agents implementing this MIB for the same chassis. > > I hope I have captured the consensus reached in discussions at wg > meetings and via email, but I thought it might be useful to get > your feedback on this text before asking Dave to add it to the draft. > > Thanks, > Keith. > ------------ > > 5.5 What is a "Chassis" > > This MIB applies to a chassis. In its normal sense, a "chassis" is > a collection of traditionally discrete network devices packaged in > a single cabinet and power supply. Indeed, the descriptions of the > objects are phrased assuming such a "physical" chassis. However, > these descriptions are not intended to exclude the application of > this MIB to a "logical chassis". Examples of such logical chassis > might be: > > - a building containing many network devices, where each room in the > building might be considered as a logical "slot", > > - a geographical area containing many network devices, where each > building in the area might be considered as a logical "slot". > > Note also that the MIB implementations for multiple (physical or > logical) chassis might be arranged hierachically, i.e., a module/entity > represented in one agent's chassis MIB might in fact represent a whole > (lower-level) chassis. For example, in a equipment cabinet having > multiple shelves with each shelf having multiple plug-in cards, the > whole cabinet could be represented by an overall chassis MIB in which > each "slot" represents a shelf, and there might also be individual > chassis MIBs for each shelf in which each slot represents where the > plug-in cards live. > > 5.6 Multiple Instanciations > > For each (logical or physical) chassis, it is possible to have multiple > agents implement this MIB for the same chassis. However, there is no > requirement to have more than one agent per chassis implement this > Chassis MIB. When multiple agents do implement this MIB for the same > chassis, there is no "master" (in the sense of a point of control), > and each agent must implement all mandatory parts of the MIB and each > contain information on all entities/modules/segments in the chassis. > Furthermore, the information in each such agent must be semantically > identical (i.e., absolute values must be identical, and relative values > must be equivalent). >
- New overview text in Chassis MIB Keith McCloghrie
- Re: New overview text in Chassis MIB David L. Arneson (arneson@ctron.com)
- Re: New overview text in Chassis MIB James R. (Chuck) Davin
- Re: New overview text in Chassis MIB Keith McCloghrie
- Re: New overview text in Chassis MIB Keith McCloghrie
- Re: New overview text in Chassis MIB Manu Kaycee
- Re: New overview text in Chassis MIB Bob Stewart
- Re: New overview text in Chassis MIB Bob Stewart