CURRENT_MEETING_REPORT_ Reported by Donna McMaster/SynOptics Minutes of the IEEE 802.3 Hub MIB Working Group (HUBMIB) The meeting was called to order by Co-Chairs Keith McCloghrie and Donna McMaster. Agenda o Introduction o Chassis MIB presentation (Keith) o Repeater ID discussion and resolution o Report on IEEE 802.3 Hub Management ballot (Donna) o Discussion of outstanding issues - From Section 8 of the current draft - From the mailing list since the Atlanta meeting - New issues There were no changes to the draft, mailing list, or archive site since the last meeting. The current draft is still the July 22, 1991 version. The Working Group mailing list is hubmib@synoptics.com. Requests should be sent to hubmib-request@synoptics.com. Drafts and mail are archived in pub/hubmib on sweetwater.synoptics.com, and can be accessed using anonymous ftp. Donna will add all meeting attendees to the hubmib mailing list. Chassis MIB There has been significant discussion about the repeater ID. Several parties have expressed the opinion that the repeater ID is not the best solution to the problem of managing multiple repeaters with a single agent, but that the problem needs to be addressed. Keith presented an alternate proposal, dubbed a ``Chassis MIB.'' This MIB defines objects for managing a ``box'' containing assorted network devices such as repeaters, bridges, routers, and/or terminal servers. Keith's slides are reproduced below. CHASSIS MIB How to manage a box containing multiple modules. o Multiple Physical Modules - slots o Multiple Logical Devices - repeaters, bridges, etc. o Multiple Backplane ``Wires'' - Ethernet, Token Ring, FDDI, etc. o Power Supply - need separate MIB 1 PHYSICAL DEVICE TABLE What's in the Slot ? o Index by slot-number o Board Type - an OID, common values defined for empty and unknown o Last change - sysUpTime at last insert/removal LOGICAL DEVICE TABLE o Index by integer o Function - a sum of values, one value for each of repeater, bridge, router, terminalServer, management card, etc. o ObjectId = sysObjectId o Party - a SNMP party OID, or `noParty' o Community - community-string or empty o IpAddress - IP Address for use with community BACKPLANE WIRES TABLE o Indexed by integer o Type - an OID o Other ?? RELATION TABLE Which device(s) are in which slot(s) and connected to what wires on the backplane o Each entry represents one relation o Each entry contains three pointers: o 1st pointer is the slot number o 2nd pointer is the logical device index o 3rd pointer is the backplane wire index An entry means that the module in the indicated slot is (part of) the indicated logical device and is connected to the indicated backplane wire. EXAMPLE Slot Device Backplane 1 1 1 2 1 1 3 2 1 3 2 2 4 3 2 5 3 2 devices 1,3 are repeaters; device 2 is a bridge. Vigorous discussion ensued. There were many questions, and general enthusiasm. Some of the issues raised: 2 o Questions about physical vs. logical devices o Use netAddr instead of IP address o Multiple addresses for the same agent (router, or OOB): could make multiple entries in the device table. Would need an additional index variable for the table. o What community string does each device send in traps -- that is, if one agent represents multiple repeaters, how does the trap receiver determine which repeater is referenced by the trap? The enthusiasm threatened to use all the time allocated for discussion of repeater MIB issues, so a straw poll was taken to see if a new effort should be undertaken to develop a Chassis MIB. Straw poll question: Do people believe that the development of a Chassis MIB is a useful and feasible project? Strong consensus that a Chassis MIB is both useful and feasible, no opposition was expressed. Repeater ID Keith briefly recapped the repeater ID issue and opened the floor to debate. Several people expressed the opinion that the repeater ID is not the appropriate mechanism for handling multiple repeaters, and that energy should be directed instead toward development of a Chassis MIB. No one was speaking in favor of the repeater ID, so a straw poll was taken. Twelve people indicated preference for dropping the repeater ID; one (Jeff Case) wanted to keep the ID. When asked for comment, Jeff explained that it was a simple solution to a current, real problem, but that he knew better than to fight overwhelming odds. Donna presented a letter from IEEE 802.3 Hub Management members Kathy de Graaf (DAVID Systems), Steve Horowitz (Chipcom), and Jim Reinstedler (Ungermann-Bass), arguing to keep the repeater ID. Their conclusion is that the repeater ID ``provides a simple, inexpensive, standard, interoperable, and useful way of allowing a single agent to address multiple repeaters.'' (Full text of the letter will be published in the Proceedings.) Discussion was invited; no one had changed his/her opinion. No representatives from Chipcom or Ungermann-Bass were present to comment. Mark Schaefer from DAVID Systems declined to comment on the letter, saying that he personally prefers the Chassis MIB solution. In light of the strong consensus, the Working Group officially decided to remove the repeater ID from the MIB, effectively making the MIB definitions represent a single repeater instead of a collection of repeaters. IEEE Report Donna presented a summary of IEEE 802.3 Hub Management Task Force (802.3 3 HMTF) activities. The 802.3 HMTF circulated a draft for letter ballot in early August. The draft received 325 comments from 64 balloters, with an initial approval rate of 71 percent. All comments were addressed in meetings held at the IEEE 802 Plenary November 10-15. Enough comments were favorably resolved to raise the approval rate above the 75 percent needed to consider the ballot formally passed. 802.3 HMTF made a number of changes in their draft as a result of the comment resolution process. A new draft will be mailed out for confirmation ballot in December, closing in January. (The confirmation ballot process is intended to verify that changes address voters' concerns without creating new problems.) The overall 802.3 Working Group also chartered new activities for defining MAU management information and for rewriting the current 802.3 layer management standard in the ISO GDMO format. The MAU management effort will include such information as media type (e.g., 10BASE-T or coax) and link status. A summary of the major changes being made in the 802.3 Hub Management draft: 1. The term ``hub'' is being changed to ``repeater.'' 2. The SNMP encodings in Annex B are being replaced with a reference to the work of the IETF Hub MIB Working Group. Case questioned whether IEEE was dropping the SNMP encodings because they consider SNMP to be a ``substandard'' management protocol. Donna stated that 802.3 uses ISO GDMO encodings because their standards are forwarded to ISO after adoption by IEEE. Removing the SNMP encodings was done to acknowledge that the IEEE does not believe it appropriate to ``compete'' with the IETF in developing SNMP MIBs. However, the 802.3 HMTF is very interested in SNMP, and most of the companies represented in that group are implementing SNMP management of their repeaters. Given that strong level of interest in SNMP, their action indicates a willingness to ``trust'' the IETF Hub MIB Working Group. 3. The concept of ``groups'' was modified in several ways. The ``group'' concept has always been a logical concept with references to possible physical mappings. In the new draft, all references to physical embodiments of groups are being removed, making a group a purely logical construct. The group definition has also been changed to allow non-contiguous port numbering, and to allow ports to be added to groups or removed from groups without resetting management. Previously, a group had a fixed number of ports ``N'', and the ports in the group were numbered from 1 through N. To effect this change, the 4 groupNumberOfPorts attribute was replaced with groupPortCapacity, and a groupPortMap attribute was added. These 802.3 HMTF port/group changes generated much discussion in the IETF Hub MIB Working Group, detailed in section V below. 4. The repeater-level MJLPs counter was replaced with a per-port equivalent called ``veryLongEventReceived'' counter. 5. ExecuteSelfTest2 was considered to be redundant with the resetHub command, and was eliminated. ExecuteSelfTest1 was renamed to be execNonDisruptiveSelfTest. 6. One balloter suggested that hubHealthData should be left for vendor extensions, as it cannot be interpreted in a vendor-independent manner. After some discussion, 802.3 HMTF decided to keep hubHealthData as ``an opportunity for implementation agreements.'' 7. The shortEvents and runts counter definitions were changed, and several other counter definitions were made more clear. The ``runtMaxTime'' number (that differentiates between a long but legal collision fragment and a late collision) was debated and left unresolved. A conference call between repeater experts is being scheduled, and 802.3 HMTF agreed to let the members of the conference call specify the value to be used. The next questions for the Hub MIB Working Group (IETF flavor) are whether to incorporate these 802.3 HMTF changes in our draft, and if so, when the changes should be made. All agreed that technical changes to counter definitions must be reflected in the IETF MIB. We also agreed to wait until after the confirmation ballot closes so that our draft doesn't thrash unnecessarily. When the confirmation ballot is complete, Donna will convey the ballot results to the Working Group along with a proposal for incorporating changes. Draft Status Jeff Case suggested the draft might be ready for forwarding to Proposed Status. There were mutterings of concern over changes that might be made in this meeting. Agreement was reached to postpone the question until later in the meeting. We later agreed that we will not forward the document to the IESG. The editors will update the draft with changes from this meeting and from the IEEE confirmation ballot, and publish for discussion at the next IETF meeting. The goal will be approval of the Working Group and submission as recommended for Proposed Standard status. 5 Groups of Ports (In reference to IEEE item 3, above.) The Hub MIB Working Group members shared a strong consensus that the reason for defining port groups is to assist the user in mapping the port numbers to the physical devices. This is in direct opposition to the IEEE's direction of stating that the group mapping is purely logical. The Working Group agreed that the draft will continue to state that implementors may assign group and port numbers as desired, but that we strongly recommend that group and port mappings match the physical manifestation of the repeater as closely as possible. The Working Group agreed to accept the IEEE's change to allow ports within a group to come and go. Does this imply a need for portUpTime as well as for groupUpTime? This would add complexity to every implementation whereas having ports moving between groups/repeaters is expected to be the less common case. Much discussion, decided not to add portUpTime. Discussion of portMap. The Working Group observed that this information can be deduced from other existing objects in a single powerful Get-Next PDU (though not in a single wimpy Get PDU), and also observed that this configuration information will not change frequently. The same applies to the groupMap. Both groupMap and portMap are therefore redundant, and there was a general feeling that the overhead of collecting the information does not justify the optimization of packaging the information into a bit map. We decided that groupMap will be removed, and we will not add portMap. How to handle the table rows for groups that are removed from a repeater or ports that are removed from a group? Delete the rows? Or have a state column in the table with a ``not here'' value to indicate a port/group that has trotted off into the sunset? Jeff Case: in other such cases, we have left this to the discretion of the implementor. There was general agreement that the implementor should choose when it is appropriate to remove the table row and when it is appropriate to return a state indicating that the group/port is unavailable for service. It was further observed that ``not here'' could mean ``switched to the other repeater in this box'' or it could mean that a plug-in module was removed or had failed. There was some discussion about having an operState column that could be used for various flavors of broken or ``not here.'' This idea was greeted favorably, and discussed with other objects later in the meeting (below). Issues from Draft Section 8 Some of the section 8 issues had been previously resolved; we covered them briefly just for completeness. Numbers below correspond to Section 8 headings. 8.1. Optional groups: agreed to keep all three groups (mandatory Basic, optional Monitor and Address Tracking). 6 8.2. Multiple repeaters: removing repeater ID, see II above. 8.3. System objects (rptrBasManufacturer, rptrBasProduct, rptrBasVersion): agreed to take them out. 8.4. Health information: Agreed to take out rptrHealthData. Should be in vendor-specific MIBs, since it cannot be decoded in a standard way. ``If people implement this instead of something that users can understand, we've done a disservice.'' 8.5. Additional group information: Keith showed a matrix of administrative objects relating to repeater, groups, and ports, and the Working Group discussed which administrative objects should be included for each of the three. The resulting table is shown below. The only changes from the current draft are in the operState column. Details of the proposed changes are listed below the matrix. ----------+-----------+-----------+-----------+-----------+----------- | admin | oper | reset | self | upTime | state | state | | test | ----------+-----------+-----------+-----------+-----------+----------- repeater | NO | YES (1) | YES | YES | NO ----------+-----------+-----------+-----------+-----------+----------- group | NO | YES (2) | NO | NO | YES ----------+-----------+-----------+-----------+-----------+----------- port | YES | YES (3) | NO | NO | NO ----------+-----------+-----------+-----------+-----------+----------- 1. Rename rptrHealthState to be rptrOperState. 2. Add new groupOperState object. 3. Add new portOperState object. Some discussion about whether this should be combined with autoPartitionState. Donna disagreed, because autoPartitionState is very specifically defined for repeater hardware. Agreed to define enumerations for portOperState and see then whether combining with autoPartitionState makes sense. 8.6. Carefully-crafted counter comments: committee condemns; clearly cannot condone. Issues from Mailing List Keith had slides listing all issues discussed on the mailing list since the last meeting, and the Working Group addressed each of them in turn. Broadcast, Multicast Counters: These were not included in IEEE and earlier IETF drafts because they can be collected by a promiscuous 7 monitor anywhere in the unbridged LAN segment and mapped to senders using the packets' source addresses. After discussion, there was agreement not to add broadcast, multicast counters. Total Counters Discussed optimizing the collection of counts for a repeater by offering repeater (or even group?) total counts. This issue is similar to the portMap/groupMap issue, but counters (esp. errors) need to be collected much more frequently in order to track the health of the network. Also, it is not unusual for a single repeater to have over 100 ports, causing high collection overhead. After discussion, the Working Group agreed that total counts are appropriate for some set of information. Proponents of totals are asked to submit proposed sets of total counters to the mailing list for further discussion. Suggestion from Bob Faulk regarding address search object: No one expressed interest in pursuing this proposal, and it was suggested that it was more appropriate as a vendor extension. New Issues No new issues were brought up, primarily due to lack of time. IEEE 802.3 Hub Management Letter To: Donna McMaster Keith McCloghrie Repeater Management MIB Working Group IETF From: Kathy de Graaf Steve Horowitz Jim Reinstedler For over two years we, as members of the IEEE 802.3 Repeater Management Task Force, have worked very hard to develop a standard for managing IEEE 802.3 repeaters. 802.3 has approved the current draft in a letter ballot, and on November 14, 1991 affirmed this work by voting overwhelmingly to send the current draft to a confirmation ballot. The members of the 802.3, representing almost all the major hub vendors, have considerable experience not only in instrumenting but also in configuring manageable hubs. Although much of this draft is directed toward instrumentation for fault and performance management, considerable effort was also expended to model the real repeater products that exist in the marketplace. A repeater is frequently implemented as one or more cards in a modular hub having multiple backplane connections and with a single agent managing the hub. These hubs may contain multiple repeaters and have the ability to dynamically create and delete groups of ports or individual ports. 8 While not all products have all these features, we did reach a consensus on features in the repeater MIB that correctly and usefully model either a high- end or low-end repeater without unduly burdening the simpler repeaters. Two years ago only a minority of the task force supported attributes that were primarily for configuration, but as we realized (from discussion and implementation) that it was both practical and desirable to provide such attributes, an overwhelming and persistent consensus developed in their favor. One example that has recently been controversial in the IETF is the use of hubID (now repeaterID) to distinguish one of many repeaters within a hub enclosure. We have found that this provides a simple, inexpensive, standard, interoperable, and useful way of allowing a single agent to address multiple repeaters, and thus urge that it be retained. We, as members of the IEEE 802.3 Repeater Management task force, therefore hope that the RM MIB Working Group will consider preserving not only the IEEE attributes directed towards fault and performance instrumentation, but also those provided for configuration management. Attendees Miriam Amos Nihart miriam@decwet.zso.dec.com Karl Auerbach karl@eng.sun.com Steve Bostock steveb@novell.com David Bridgham dab@asylum.sf.ca.us Jeffrey Case case@cs.utk.edu James Codespote jpcodes@tycho.ncsc.mil Dave Cullerot cullerot@ctron.com James Davin jrd@ptt.lcs.mit.edu Michael Erlinger mike@lexcel.com Jeff Erwin Bill Fardy fardy@ctron.com Shawn Gallagher gallagher@quiver.enet.dec.com Greg Hollingsworth gregh@mailer.jhuapl.edu Satish Joshi sjoshi@synoptics.com Frank Kastenholz kasten@europa.clearpoint.com Manu Kaycee kaycee@ctron.com Yoav Kluger ykluger@fibhaifa.com Cheryl Krupczak cheryl@cc.gatech.edu Ron Lau rlau@synoptics.com Keith McCloghrie kzm@hls.com Evan McGinnis bem@3com.com Donna McMaster mcmaster@synoptics.com David Minnich dwm@fibercom.com Lynn Monsanto monsanto@sun.com Anil Rijsinghani anil@levers.enet.dec.com Mark Schaefer schaefer@davidsys.com Timon Sloane peernet!timon@uunet.uu.net Bob Stewart rlstewart@eng.xyplex.com Bruce Taber taber@interlan.com 9 Iris Tal 437-3580@mcimail.com June-Kang Yang natadm!yang@uunet.uu.net John Ziegler ziegler@artel.com 10