This is only a rough draft - Megan 04/20/92 Minutes of IETF 802.3 Hub MIB Working Group 18 March 1992 meeting in San Diego The meeting was called to order at 9:30 by co-Chairs Donna McMaster and Keith McCloghrie. Agenda IETF SNMP Hub MIB Working Group 18 March 1992, San Diego, CA 1. IEEE 802.3 Repeater Management Report 2. Outstanding Issues from Chapter 8 of latest Draft 3. Issues from Mailing List 4. Any other issues on latest Internet Draft 5. Discussion of MAU MIB 6. MAU MIB Strategy 7. Plans for Progression of Document(s) A new (March 6) version of the Repeater MIB draft was distributed. This incorporated the text, updated in light of IEEE 802.3 Repeater Management Task Force's February meeting, and previously distributed to the working group's mailing-list. IEEE REPORT Donna presented the following report on the progress of the IEEE 802.3 Repeater Mgmt Task Force (formerly known as "Hub Mgmt TF"): ------------------------------------------------------------------------- IEEE 802.3 Rptr Mgmt Progress - Confirmation ballot closed Jan 31 - 82 comments, primarily requesting clarification - At interim meeting Feb 24-26, rewrote section "Port Functions to Support Mgmt," provided initial resolution for all comments - At IEEE 802 plenary last week, minor tweaks, sending results for 2nd confirmation ballot, prognosis is very good - March 6 draft of SNMP Repeater MIB is based on output of interim - For next draft, editors plan to do "tweaks" from last week's plenary along with other changes that come out of this meeting - MAU MIB is now the hot topic ------------------------------------------------------------------------- Geoff Thompson reported on the minor "tweaks" from the IEEE meeting in Irvine the previous week. These edits will be incorporated into the next draft of the Repeater MIB. OUTSTANDING ISSUES FROM CHAPTER 8 The meaning of the enumerated value notPresent for the MIB object rptrGroupOperState was discussed. It was questioned whether the "has been physically removed" wording used in the document implied that the removal must have occurred since the last reboot. Lengthy discussion identified numerous suggestions, including: a. delete the word "physically"; b. change "has been" to "is"; c. delete the notPresent state and have the instance not appear in the MIB when the group was not present; d. allow implementation flexibility; e. add more enumerations to distinguish: "physically present and logically notPresent", "physically notPresent and logically notPresent", "physically can't ever be present", and "physically can't be present at the moment"; f. add more definitive/instructive text; g. purposely be vague in the text. After several votes, a consensus eventually emerged to add more definitive/ instructive text while leaving the enumerations as they were. In order to make progress, two attendees volunteered to draft additional text while the next item was discussed. The next item was whether rptrPortAutoPartitionState should be combined with rptrPortOperState into a single MIB object. After some discussion the MIB objects were left as being separate. Discussion of the seriousness of autoPartition and the overhead in polling every port's autoPartition state on a regular basis. We do not want to issue a trap when this happens. Instead the group agreed to add a new repeater-level object "total partitioned ports" with syntax of Gauge. This object will represent the total number of ports in the repeater that are currently enabled and present but autoPartitioned. On the issue of Total Counters, it was agreed that while a total counter was redundant in the sense that it was a sum of other counters already represented as MIB objects, it was most beneficial in reducing the amount of network traffic, particularly on repeaters with many (e.g., over a hundred) ports. Two such counters were suggested: one was Total Errors per port, as suggested by the editors in the draft. It was agreed that the errors included in this total would be: rptrMonitorPortFCSErrors, rptrMonitorPortAlignmentErrors rptrMonitorPortFrameTooLongs, rptrMonitorPortShortEvents rptrMonitorPortLateEvents, rptrMonitorPortDataRateMismatches and rptrMonitorPortVeryLongEvents The other total counter was the number of frames across all ports. The difficulty was observed of how this counter would behave when one or more of the ports were removed. A decrease in the counter's value was not consistent with the syntax of Counter. Various suggestions were made: a. count the total number since the last group (re-)configuration, adding a timestamp to record when that occurred; b. add a 'virtual port' which would conceptually be a promiscuous monitor on all ports. c. have a total counter per group rather than per repeater. The consensus emerged to have three total counters associated with each group: - groupTotalFrames - groupTotalOctets - groupTotalErrors On the issue of counting FramesTooLong and VeryLongEvents, the consensus was to align with IEEE, and count them all. The new text from the two volunteers for rptrGroupOperState was reviewed. The consensus was that either would be acceptable. A slight majority preferred the following text: "notPresent(x) indicates that the group is temporarily or permanently physically and/or logically not a part of the repeater. It is an implementation-specific matter as to whether the agent effectively removes notPresent entries from the table." The group also agreed to change rptrGroupUpTime to be rptrGroupOperStateLastChange (or some abbreviation of this) with the customary semantics. DISCUSSION OF MAU MIB A first draft of the MAU MIB was distributed. (This document was also mailed to the hubmib mailing list on Friday, March 13.) Donna presented the following overview of MAU management status and issues: ------------------------------------------------------------------------- IEEE 802.3 MAU Mgmt - 802.3 Medium Attachment Unit (MAU) attaches repeater port or Ethernet- like interface to the local network medium - MAU types include 10BASE5 (thick coax), 10BASE2 (thin coax), 10BASE-T (twisted pair), FOIRL and 10BASE-F (fiber optic) - MIB information includes MAU type, link status, jabbering - Discussions in IEEE 802.3 Hub Mgmt group over past year, postponed MAU work to finish Repeater Mgmt - Draft proposal brought to interim meeting, well-received, more work done at plenary - Draft of SNMP MAU MIB mailed to mailing list last Friday, based on output from IEEE 802.3 plenary - Later in today's meeting will discuss how IETF Hub MIB WG wants to handle the MAU MIB ------------------------------------------------------------------------- MAU MIB Objects 1. MAU Type 2. Admin State (operational, standby, shutdown) - Option to implement as read/write, reset MAU 3. Media Available - Link status (link integrity/low light) for link media (10BASE-T or 10BASE-F), loopback normal for coax media - Lost media counter indicates stability of medium 4. Jabber state, jabbers counter - Jabbering (continuous transmission) indicates serious problem in host, not as interesting for repeater ports 5. Jabber trap ------------------------------------------------------------------------- MAU MIB Questions - MAU can attach to repeater port or DTE (Ethernet interface), therefore related to both Repeater MIB and Ethernet-like Itfs MIB - Most objects are common to both port MAUs and interface MAUs - Multiple MAUs can be attached to a single port or interface - How to instantiate? For rptr ports, "group.port.mau" is desireable, for interfaces, "interface.mau". Stay tuned... ------------------------------------------------------------------------- MAU MIB Options (none perfect!) 1. Add MAU tables to Repeater and Ethernet-like Interfaces MIBs: - MAU table in Repeater MIB indexed "group.port.mau" - MAU table in Ethernet-like Ifs MIB indexed "interface.mau" -> Destabilizes both drafts, bad timing 2. Create new MAU MIB document with MAU table, indexed 1..n. - Add two tables that give mappings from port -> MAU, interface -> MAU. -> Awkward instantiation when using MIB browser 3. Create two new MAU MIBs in separate documents (or combine) - Repeater MAU MIB with table indexed "group.port.mau" - Etherlike Ifs MAU MIB with table indexed "interface.mau" -> Duplicates much information ------------------------------------------------------------------------- Some discussion. People agreed that the application of the MAU information to Repeaters comes within the charter of this working group. However, it was suggested that we didn't want to slow down the progress of the current Repeater MIB draft, and so the meeting agreed to treat this as a separate MIB document to be produced by the working group. With little time remaining in the meeting, the group also agreed to deal with MAUs separately for repeaters and for interfaces, but there was no time for any other discussion of the MAU MIB at this meeting. Attendees were encouraged to raise any/all issues on the mailing-list. ISSUES FROM THE MAILING-LIST The issue of the interaction between rptrPortOperStatus and rptrPortAdminStatus had been raised on the mailing-list since the meeting in Santa Fe. All agreed that they should have the same interaction as MIB-II's ifOperStatus and ifAdminStatus, but there was confusion of ifOperStatus's semantics. Explanation that ifOperStatus was defined to become 'down' as soon as possible after ifAdminStatus was set to 'down' resolved the confusion. ANY OTHER ISSUES No other issues were raised. PROGRESSION OF DOCUMENTS The editors were chartered to update the Repeater MIB draft in light of the agreements at this meeting, and to distribute to the mailing list within two weeks. Thereafter, the working group would have two weeks to review it. If no concerns were raised on the mailing-list within the following 2 weeks (or if all raised concerns were satisfactorily resolved), then the Repeater MIB would be done, and should be forwarded to the IESG with a recommendation for being progressed to Proposed Standard status. Meanwhile, the MAU MIB would be discussed on the mailing-list. Attendees Jim Barnes barnes@xylogics.com Steve Bostock steveb@novell.com Jack Brown jbrown@huahuca-emh8.army.mil Niels Ole Brunsgaard nob@dowtyns.dk Lida Canin lida@apple.com Jeffrey Case case@cs.utk.edu Carson Cheung carson@bnr.com.ca Dave Cullerot cullerot@ctron.com David Engel david@cds.com Bob Friesenhahn pdrusa!bob@uunet.uu.net Shawn Gallagher gallagher@quiver.enet.dec.com Mike Grieves mgrieves@chipcom.com Walter Guilarte 70026.1715@compuserve.com Frank Kastenholz kasten@europa.clearpoint.com Manu Kaycee kaycee@ctron.com Mark Kepke mak@cnd.hp.com Yoav Kluger ykluger@fibhaifa.com Dave Lindemulder da@mtung.att.com Richie McBride rm@bix.co.uk Keith McCloghrie kzm@hls.com Evan McGinnis bem@3com.com Donna McMaster mcmaster@synoptics.com Edison Paw esp@3com.com Jim Reinstedler jimr@sceng.ub.com Sam Roberts sroberts@farallon.com Dan Romascanu dan@lannet.com Marshall Rose mrose@dbc.mtview.ca.us Rick Royston rick@lsumus.sncc.lsu.edu Michael Sabo sabo@dockmaster.ncsc.mil Mark Schaefer schaefer@davidsys.com Timon Sloane peernet!timon@uunet.uu.net Bob Stewart rlstewart@eng.xyplex.com Mark Therieau markt@python.eng.microcom.com Geoff Thompson thompson@synoptics.com Timothy Walden tmwalden@saturn.sys.acc.com Steve Wong wong@took.enet.dec.com Paul Woodruff paul-woodruff@3com.com Brian Wyld brianw@spider.co.uk Henry Yip natadm!henry@uunet.uu.net