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