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).
>