home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / chassis / chassis-minutes-92mar.txt < prev    next >
Text File  |  1993-02-17  |  9KB  |  215 lines
  1. This is only a rough draft - Megan 04/16/92
  2.  
  3. The following meeting agenda was presented on the Chassis MIB
  4. working group mailing list before the meeting.
  5.  
  6. -----------------------------------------------------------
  7.  
  8. Chassis MIB WG -- March 17, 1992
  9.  
  10. Bob Stewart
  11. rlstewart@eng.xyplex.com
  12.  
  13. Jeff Case
  14. case@cs.utk.edu
  15.  
  16. Mailing List:  chassismib@cs.utk.edu
  17. chassismib-request@cs.utk.edu to add/delete/modify
  18.  
  19.     Welcome
  20.  
  21.     Introductions
  22.  
  23.     Review Charter
  24.  
  25.     Chassis Information Model
  26.  
  27.     Define Scope of Work
  28.  
  29.     Review Contributed MIBs
  30.  
  31.         Keith McCloghrie, Hughes LAN Systems (kzm@hls.com) and
  32.         Donna McMaster, Synoptics (mcmaster@synoptics.com)
  33.  
  34.         Manu Kaycee, Cabletron (kaycee@ctron.com)
  35.  
  36.     Plan For Producing Baseline Documents
  37.  
  38.     Next Meeting Date and Location
  39.  
  40. -----------------------------------------------------------
  41.  
  42. We discussed the charter, concentrating on the three work areas:
  43. mapping logical functions to physical devices, power supplies, and
  44. aggregation.  This discussion was limited to the meaning of the
  45. charter with technical discussion deferred to later in the
  46. meeting.
  47.  
  48. The major points regarding the charter for logical to physical
  49. mapping (the Chassis MIB, proper) were:
  50.  
  51.    .  This is a "meta-MIB", pointing to other MIBs.
  52.    .  Multiple instances of the same device may have "virtual
  53.       agents."
  54.    .  Any system in any slot may implement the Chassis MIB.
  55.    .  One agent may point all slots to the same agent.
  56.  
  57. The major points regarding the charter for a power supply MIB
  58. were:
  59.  
  60.    .  "Power supply" may include environment, such as fans and
  61.       temperature.
  62.    .  "Power supply" most likely does not include items such as
  63.       interrupt vectors and memory jumpers.
  64.    .  Environment perhaps should be a separate MIB.
  65.    .  Discussion should stay focussed on a "network" chassis, not
  66.       general VME, Multibus, PC bus or such.
  67.  
  68. Little was said at this point regarding aggregation.
  69.  
  70. Regarding the general constraints, the major points were:
  71.  
  72.    .  This is NOT the place for a VME MIB.
  73.    .  Large companies, such as IBM, are not considered as
  74.       standards bodies.
  75.    .  For the sake of robustness, reliance on third parties is to
  76.       be avoided.
  77.  
  78. The charter was accepted as written.
  79.  
  80. The group discussed the scope of work for a Power Supply MIB.  The
  81. major points were:
  82.  
  83.    .  Many are interested having such a MIB, few are interested
  84.       in working on it.
  85.    .  A document is not useful if it does not result in
  86.       widespread implementations.
  87.    .  A poll of what current implementations provide obtained:
  88.       state, backup, voltage, current, etcetera ad nauseum.
  89.    .  A Power Supply MIB might point to an Environment MIB.
  90.    .  A Power Supply MIB is applicable outside a chassis, but a
  91.       power supply in a chassis is more important than in a
  92.       single system.
  93.    .  What is available across implementations resulted in a
  94.       consensus for on/off status and an average of 4/5 variables
  95.       from about 25 companies.
  96.    .  Who is actually using this information resulted in
  97.       responses from Hughes, Digital, Synoptics, Chipcom,
  98.       Fibronics, NCR, and several others.
  99.    .  Everyone who has such variables is to send relevant MIB
  100.       segments to Bob Stewart for compilation, including
  101.       temperature, fans, and such.
  102.  
  103. The group discussed the scope of work for aggregate information.
  104. The major points were:
  105.  
  106.    .  Widespread confusion over what this topic means concluded
  107.       that this is to be an assessment of "how is it (a group of
  108.       entities) working".
  109.    .  The answer to "Why with the Chassis MIB?" was because a
  110.       chassis creates a well-identified group.
  111.    .  The group agreed the definition is still to vague, what
  112.       constitutes a group?
  113.    .  Is there anything like this now?  There is some CMIP work
  114.       which will be one of our proposals, along with two others.
  115.    .  Examples of aggregation are total errors, total packets,
  116.       and such.
  117.    .  Jeff wants to do this.
  118.    .  Some specific examples are traffic in and out of a regional
  119.       network, or the sum of ifInOctets for a group.
  120.    .  Might this solve the problem of SNMP management for non-
  121.       SNMP devices not necessarily in a chassis?  No.
  122.    .  This is an interesting next step in network management, but
  123.       may be beyond the reasonable scope of this working group.
  124.    .  Synoptics has a MIB for the health of a device, set by
  125.       rules.
  126.    .  The RMON MIB totals things, but is LAN-bound.
  127.    .  This looks like artificial intelligence.
  128.    .  In favor of this work, but shouldn't be called "chassis."
  129.    .  Does the rule of not defining objects deducible from others
  130.       preclude this?  No, that was a rule for initial definition
  131.       of MIB I.
  132.    .  Conclusion was that this is useful, important work, many
  133.       want to work on it and want the product of that work.
  134.  
  135. The working group concluded that the Chassis MIB is of primary
  136. importance, a Power Supply MIB is worth working on if there is
  137. enough common ground, and an Aggregation MIB may combine in some
  138. ways with the Chassis MIB or may need to be separated so as not to
  139. adversely effect delivery of a Chassis MIB, which is the primary
  140. deliverable.
  141.  
  142. The working group then turned to presentations of possible Chassis
  143. MIBs.
  144.  
  145. Keith McCloghrie presented a proposed Chassis MIB that he and
  146. Donna McMaster prepared for the Multiport Repeater Working Group.
  147. [The McChassis MIB?]  The major points presented were:
  148.  
  149.    .  Purpose is to manage a box with multiple modules.  The box
  150.       comprises physical modules (slots), logical devices
  151.       (repeaters, bridges, etc.), backplane "wires" (Ethernet,
  152.       Token Ring, FDDI, etc.), and power supply.
  153.    .  Physical devices are indexed by slot number.  They have an
  154.       object identifier for board type (including empty and
  155.       unknown), and a time of last insertion or removal.
  156.    .  Logical devices are integer indexed.  They have a function
  157.       (a sum of values such as repeater, bridge, or terminal
  158.       server), the device's sysObjectId, and, for SNMP access, an
  159.       SNMP party object identifier or a community string and IP
  160.       address.  Issues here included relationship to SMUX and UPD
  161.       ports, non-IP addressing, and multiple communities for get
  162.       and set.
  163.    .  Backplane wires are integer indexed and have an object
  164.       identifier to indicate type.
  165.    .  A configuration table has an entry for each relation with a
  166.       slot number, a logical device index, and a backplane wire
  167.       index, meaning that (part of) the logical device is in the
  168.       slot and connected to the indicated backplane wire.
  169.       Several such entries may make up a single logical device.
  170.    .  Concepts in the document but not on the original slides
  171.       include a status object and a null index to indicate lack
  172.       of relevance, such as no backplane wire for a power supply.
  173.    .  Additional issues include definition of "chassis",
  174.       generalization of "slot" to include "physical device," more
  175.       information such as ifIndex or ifOperStatus, inclusion of
  176.       external "wires," what is a proper device (such as a host),
  177.       a directory of devices beyond a chassis, and the number of
  178.       tables (done to be concise).
  179.  
  180. Manu Kaycee presented a Chassis MIB being implemented as a private
  181. extension by Cabletron.  The major points presented were:
  182.  
  183.    .  Requirements are to support hub-based products, many-to-
  184.       many associations, logical and physical representations,
  185.       physical partitioning of components and tables, MIB
  186.       discovery, multiple component instances, virtual chassis.
  187.    .  MIB is very similar to Keith and Donna's.
  188.    .  Lacks map from logical device to backplane wires.
  189.    .  Adds chassis type for agent-supporting device.
  190.    .  Backplane includes VME or such.
  191.    .  Has a slot count.
  192.    .  Component table includes adminStatus (needs operStatus),
  193.       string to pass with initialize command, name, software
  194.       version, access policy.
  195.    .  Slot table indexed by slot and component to give map.  It
  196.       includes slot class for restricted slots, a unique module
  197.       ID, and is empty if "chassis" is slotless.
  198.    .  Includes a (controversial) MIB group table, indexed by
  199.       slot, component, and group that can distribute the MIB-II
  200.       ifTable across slots and could be VERY big.
  201.    .  This is currently being implemented, Cabletron will share
  202.       experience if that is helpful.
  203.  
  204. Jeff called for additional proposals.  Two were offered to be
  205. submitted by mid April.  First draft MIB to appear as soon as
  206. possible after final call for proposals on mailing list.
  207.  
  208. The working group decided not to have an interim meeting,
  209. especially not at Interop.  Discussion will be via email.
  210.  
  211. Respectfully submitted,
  212.  
  213.      Bob Stewart
  214.  
  215.