Minutes of San Diego Meeting

[Bob Stewart <[e-mail]>]

Chassis MIB Working Group Minutes
Bob Stewart, Xyplex, [e-mail]

The Chassis MIB Working Group held its first meeting at the IETF
meeting in San Diego, at 7:00 PM on Tuesday, 17 March 1992.  For
this meeting, Jeff Case presided and Bob Stewart recorded.  The
meeting was well-attended, with lively discussion.  Overall, the
meeting showed good consensus and resulted in the completion of
the business at hand.  An archive will be set up at cs.utk.edu for
anonymous FTP.

The following meeting agenda was presented on the Chassis MIB
working group mailing list before the meeting.

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

Chassis MIB WG -- March 17, 1992

Bob Stewart
[e-mail]

Jeff Case
[e-mail]

Mailing List:  [e-mail]
[e-mail] to add/delete/modify

    Welcome

    Introductions

    Review Charter

    Chassis Information Model

    Define Scope of Work

    Review Contributed MIBs

        Keith McCloghrie, Hughes LAN Systems ([e-mail]) and
        Donna McMaster, Synoptics ([e-mail])

        Manu Kaycee, Cabletron ([e-mail])

    Plan For Producing Baseline Documents

    Next Meeting Date and Location

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

We discussed the charter, concentrating on the three work areas:
mapping logical functions to physical devices, power supplies, and
aggregation.  This discussion was limited to the meaning of the
charter with technical discussion deferred to later in the
meeting.

The major points regarding the charter for logical to physical
mapping (the Chassis MIB, proper) were:

   .  This is a "meta-MIB", pointing to other MIBs.
   .  Multiple instances of the same device may have "virtual
      agents."
   .  Any system in any slot may implement the Chassis MIB.
   .  One agent may point all slots to the same agent.

The major points regarding the charter for a power supply MIB
were:

   .  "Power supply" may include environment, such as fans and
      temperature.
   .  "Power supply" most likely does not include items such as
      interrupt vectors and memory jumpers.
   .  Environment perhaps should be a separate MIB.
   .  Discussion should stay focussed on a "network" chassis, not
      general VME, Multibus, PC bus or such.

Little was said at this point regarding aggregation.

Regarding the general constraints, the major points were:

   .  This is NOT the place for a VME MIB.
   .  Large companies, such as IBM, are not considered as
      standards bodies.
   .  For the sake of robustness, reliance on third parties is to
      be avoided.

The charter was accepted as written.

The group discussed the scope of work for a Power Supply MIB.  The
major points were:

   .  Many are interested having such a MIB, few are interested
      in working on it.
   .  A document is not useful if it does not result in
      widespread implementations.
   .  A poll of what current implementations provide obtained:
      state, backup, voltage, current, etcetera ad nauseum.
   .  A Power Supply MIB might point to an Environment MIB.
   .  A Power Supply MIB is applicable outside a chassis, but a
      power supply in a chassis is more important than in a
      single system.
   .  What is available across implementations resulted in a
      consensus for on/off status and an average of 4/5 variables
      from about 25 companies.
   .  Who is actually using this information resulted in
      responses from Hughes, Digital, Synoptics, Chipcom,
      Fibronics, NCR, and several others.
   .  Everyone who has such variables is to send relevant MIB
      segments to Bob Stewart for compilation, including
      temperature, fans, and such.

The group discussed the scope of work for aggregate information.
The major points were:

   .  Widespread confusion over what this topic means concluded
      that this is to be an assessment of "how is it (a group of
      entities) working".
   .  The answer to "Why with the Chassis MIB?" was because a
      chassis creates a well-identified group.
   .  The group agreed the definition is still to vague, what
      constitutes a group?
   .  Is there anything like this now?  There is some CMIP work
      which will be one of our proposals, along with two others.
   .  Examples of aggregation are total errors, total packets,
      and such.
   .  Jeff wants to do this.
   .  Some specific examples are traffic in and out of a regional
      network, or the sum of ifInOctets for a group.
   .  Might this solve the problem of SNMP management for non-
      SNMP devices not necessarily in a chassis?  No.
   .  This is an interesting next step in network management, but
      may be beyond the reasonable scope of this working group.
   .  Synoptics has a MIB for the health of a device, set by
      rules.
   .  The RMON MIB totals things, but is LAN-bound.
   .  This looks like artificial intelligence.
   .  In favor of this work, but shouldn't be called "chassis."
   .  Does the rule of not defining objects deducible from others
      preclude this?  No, that was a rule for initial definition
      of MIB I.
   .  Conclusion was that this is useful, important work, many
      want to work on it and want the product of that work.

The working group concluded that the Chassis MIB is of primary
importance, a Power Supply MIB is worth working on if there is
enough common ground, and an Aggregation MIB may combine in some
ways with the Chassis MIB or may need to be separated so as not to
adversely effect delivery of a Chassis MIB, which is the primary
deliverable.

The working group then turned to presentations of possible Chassis
MIBs.

Keith McCloghrie presented a proposed Chassis MIB that he and
Donna McMaster prepared for the Multiport Repeater Working Group.
[The McChassis MIB?]  The major points presented were:

   .  Purpose is to manage a box with multiple modules.  The box
      comprises physical modules (slots), logical devices
      (repeaters, bridges, etc.), backplane "wires" (Ethernet,
      Token Ring, FDDI, etc.), and power supply.
   .  Physical devices are indexed by slot number.  They have an
      object identifier for board type (including empty and
      unknown), and a time of last insertion or removal.
   .  Logical devices are integer indexed.  They have a function
      (a sum of values such as repeater, bridge, or terminal
      server), the device's sysObjectId, and, for SNMP access, an
      SNMP party object identifier or a community string and IP
      address.  Issues here included relationship to SMUX and UPD
      ports, non-IP addressing, and multiple communities for get
      and set.
   .  Backplane wires are integer indexed and have an object
      identifier to indicate type.
   .  A configuration table has an entry for each relation with a
      slot number, a logical device index, and a backplane wire
      index, meaning that (part of) the logical device is in the
      slot and connected to the indicated backplane wire.
      Several such entries may make up a single logical device.
   .  Concepts in the document but not on the original slides
      include a status object and a null index to indicate lack
      of relevance, such as no backplane wire for a power supply.
   .  Additional issues include definition of "chassis",
      generalization of "slot" to include "physical device," more
      information such as ifIndex or ifOperStatus, inclusion of
      external "wires," what is a proper device (such as a host),
      a directory of devices beyond a chassis, and the number of
      tables (done to be concise).

Manu Kaycee presented a Chassis MIB being implemented as a private
extension by Cabletron.  The major points presented were:

   .  Requirements are to support hub-based products, many-to-
      many associations, logical and physical representations,
      physical partitioning of components and tables, MIB
      discovery, multiple component instances, virtual chassis.
   .  MIB is very similar to Keith and Donna's.
   .  Lacks map from logical device to backplane wires.
   .  Adds chassis type for agent-supporting device.
   .  Backplane includes VME or such.
   .  Has a slot count.
   .  Component table includes adminStatus (needs operStatus),
      string to pass with initialize command, name, software
      version, access policy.
   .  Slot table indexed by slot and component to give map.  It
      includes slot class for restricted slots, a unique module
      ID, and is empty if "chassis" is slotless.
   .  Includes a (controversial) MIB group table, indexed by
      slot, component, and group that can distribute the MIB-II
      ifTable across slots and could be VERY big.
   .  This is currently being implemented, Cabletron will share
      experience if that is helpful.

Jeff called for additional proposals.  Two were offered to be
submitted by mid April.  First draft MIB to appear as soon as
possible after final call for proposals on mailing list.

The working group decided not to have an interim meeting,
especially not at Interop.  Discussion will be via email.

Respectfully submitted,

     Bob Stewart