NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Dan Romascanu <email@example.com>
Operations and Management Area Director(s):
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <firstname.lastname@example.org>
Operations and Management Area Advisor:
Bert Wijnen <email@example.com>
To Subscribe: firstname.lastname@example.org
Description of Working Group:
The Ethernet Interfaces and Hub MIB WG is Chartered to define a set of managed objects that instrument devices (repeaters, MAUs, interfaces) that conform to the IEEE 802.3 standard for Ethernet.
This set of objects should be largely compliant with, and even draw from IEEE 802.3, although there is no requirement that any specific object be present or absent.
The MIB object definitions produced will be for use by SNMP and will be adequately consistent with other SNMP objects, standards and conventions.
Goals and Milestones:
Meet at the 41st IETF to discuss implementation experience of RFC 2108 and RFC 2239, and to consider future extensions for Full Duplex operation and 1 Gigabit Ethernet Speeds
Gather implementation experience feedback concerning RFC 2108 and RFC 2239
Post Internet-Draft(s) for Full Duplex and 1 Gigabit Ethernet MIB extensions
Meet at the 42nd IETF to discuss the Internet-Draft(s) and issue recomendations concerning advancement of RFC 2108 and RFC 2239 on the standards track
Post revised Internet-Draft(s)
Conduct WG Last Call on Internet-Draft(s)
Submit final version of the Internet-Draft(s) to the IESG for consideration as Proposed Standards
Request For Comments:
Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)
Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2
Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2
Definitions of Managed Objects for the Ethernet-like Interface Types
Minutes of the HUBMIB Working Group at the 42nd IETF Chicago, Illinois USA 27Aug98
Reported by Lynn Kubinec (email@example.com)
The chair announced the rechartering and renaming of the working group. The group is
now the Ethernet Interface and Hub MIB Working Group. The change reflects the current
focus of the work the group is doing as switches are replacing repeaters.
In terms of the charter, the group is responsible for three documents. The Repeater MIB,
which has seen no significant change recently, and the MAU and Ethernet Interfaces MIBs
which have received more emphasis.
Mailing List details were posted:
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
The working group recently faced a SPAM crisis in which a list subscriber threatened to
sue the list host over mail received by the subscriber. The incident caused a solicitation
on the list from John Flick requesting a new list host. The issue has been resolved, the
list subscriber who complained hadn't realized the mail he/she objected to was received
from the list forwarding engine and HP will continue to host the list. The chair asked,
however, that any suggestions regarding setting up list filters be sent to John Flick and
also asked for volunteers to take up the list hosting duties.
The chair presented the agenda:
1. Administrativia, Agenda Bashing
2. Results of the Implementation Survey for RFC 2108 and RFC 2239
3. MAU MIB Draft Open Issues - <draft-ietf-hubmib-mau-mib-v2-00.txt>
4. Ethernet Chipsets Registration
5. Ethernet-like Interfaces MIB Changes (1 G, registration, etc.)
Agenda was accepted as is.
The chair presented the Implementation Survey results:
For the Repeater MIB (RFC 2108), four vendors submitted surveys: 3 were agent
implementations, 1 was an NMS implementation. For the MAU MIB (RFC 2239), four
vendors reported on five implementations.
The results of the survey will be used as the basis of an Implementation Status Report to
the IESG in order to move the RFCs from Proposed to Draft Standard. In this regard, the
results of the survey are disappointing in that two of the three major vendors did not
respond to the survey. The AD wondered if these vendors are interested in progressing the
standard, the chair was not sure.
In addition to the lack of response, it came to light during the Bridge MIB working group
meeting that there is another problem with the survey. The chair had done the survey
guaranteeing responder anonymity. What was discovered in the Bridge MIB meeting is
that at least two implementation survey participants must not be anonymous. The IESG
The new MIB testing procedures were discussed. The chair explained that in addition to
the survey, MIB walks of the implementations must be performed in accordance with
Survey results were presented as posted to the mailing list. The chair presented an analysis
of the results:
Items 1, 2, 3, 4, and 6:
- rptrGroupTable, rptrPortTable, rptrInfoTable, rptrMonitorPortTable and rptrMonTable
All three agents implemented these.
Items 5 and 7: 100 Mbps Repeater Objects
- rptrMonitor100PortTable and rptrMon100Table
Only 1 agent implemented the 100 Mbps repeater related objects. The other two had 10
Mbps only repeaters.
Items 8, 9, and 10: Address Searching for Topology mapping
- rptrAddrSearchTable, rptrAddrTrackTable, rptrExtAddrTrackTable
HP Openview Release 5 (the NMS in the survey) uses this information.
It is an open question whether or not the topology related objects arenecessary.
Items 11 and 12: Statistics sorting ala RMON
- rptrTopNPortControlTable, rptrTopNPortTable
Two of the three agents reported implemented these objects
Items 13 and 14: Traps
- rptrInfoHealth, rptrInfoResetEvent
Only one vendor implemented these.
Analysis: Only items 1, 2, 3, 4, 6, 9, 11 and 12 have two implementations. At this stage
8 does not meet the requirement.
A discussion ensued regarding implementation feedback:
Jeff Johnson noted that, in general, there hasn't been a lot of feedback to these surveys at
all this week. He asked the AD how groups could get more response, perhaps by
widening the scope of those solicited to respond. The AD asked if the chair had clearly
stated that response to the survey was needed in order to advance the standard? He also
asked if the RFC had only been at proposed for six months.
The chair responded that the Repeater MIB had been at Proposed for one and a half
years and that perhaps his survey hadn't been worded clearly enough as it was combined
with mail on another topic.
The AD stated that there is an alternative to progressing on the standards track and that
is to make the RFC Informational like the UPSMIB group has decided to do and pointed
out that there is no crisis here, there are still six months left of the usual two-year time
limit to gather implementation reports.
A group member commented that perhaps the lack of responses here was related to
VLAN technology, i.e. the market moving away from repeaters to switches. The chair
concurred that this is a possibility.
Joan Cucchiara asked if an effort had been made to contact the two major Ethernet
vendors that had not responded to the survey. The chair responded that no, this had
not been done. It is expected that the mailing list participants will be pro-active and
make efforts to get a response posted to the group or chair. He pointed out that he has
no idea who to contact at a company for the information the group requires. The chair
also suggested that he could re-post the survey to the mailing list with a clearer
discussion about why it is important for vendors to respond. Joan noted that perhaps
an announcement could be sent to the SNMPv3 mailing list. The AD said this approach
should be used sparingly, perhaps once.
The chair continued the meeting with analysis of the RFC 2239 Implementation Survey.
There were five implementations from 4 vendors. Implementations V1', V2, V3 and
V4 were for bridge/router/switch products; V1 was for a repeater.
Only one vendor and doesn't implement rpMauFalseCarriers
Items 2 and 6:
- rpJackTable, broadMaubasicTable
No implementations (in addition, the rpJackTable caused quite a bit of
discussion during initial MIB development).
Items 3 and 4:
- ifMauTable, ifJackTable
Good amount of implementation reported, but ifMauFalseCarrier and
ifMauJabberStateEnters not always supported in silicon. These objects could be
candidates for deprecation.
This is a new table; two of the four vendors implement the table as read-only. Perhaps
the MIN-ACCESS conformance clause of table variables needs to be changed.
Items 7 and 9:
- rpMauJabberTrap, ifMauJabberTrap
Only one implementation.
The AD expressed surprise that no one was saying anything, especially given the initial
discussions about the rpJackTable. The chair noted that the participants in those
discussions were not at this meeting.
The next topic was the Ethernet-Like Interfaces MIB. The new draft adds objects for
Gigabit ethernet and describes the relationship of the Ethernet-Like MIB with the
Interfaces MIB. In addition, support for full duplex ethernet is added. The new objects
are derived from the IEEE 802.3 x and z standards. The draft editor, John Flick, could
not attend the meeting.
The discussion first addressed the Chip Set Registration issue. The chair gave a short
introduction of the topic. The Ethernet-Like MIB has one object that identifies a
manufacturer's chip set. The text for this one object takes up more than half the entire
draft and is larger than the rest of the MIB module itself. The IESG has asked what will
happen if new chips are introduced but the draft doesn't move through the standards
process. Can't have the working group alive forever just to update the chip set list.
Perhaps IANA should administer the list. The chair stated that IANA may require an
intermediary from the working group.
Jeff Johnson asked if the chipset information is useful.
The chair noted that there are four options:
1.) Use IEEE 802.1F Clause 126.96.36.199 and A.5 structure:
ManufacturerOUI, ManufacturerName, ManufacturerProductName, and manufacturerProductVersion
2.) Use IANA
3.) Keep it as it is
4.) Drop It
Number three is not seen as a solution.
A question about the initial reason for the object was asked. The chair explained that
part of the history is the tradition of the working group to use the IEEE standards
documents as a basis for MIBs developed. It is an IEEE idea to provide identification
for chipsets. The object can provide a very useful way to identify misbehaving chips.
Another comment was raised that the network manager would go to the OEM for help
with a misbehaving product, not to the chipset manufacturer.
Jeff Johnson commented that in his experience outside of Ethernet with micro
processors in particular was this it is good to know not only which chipset, but which
version of the chipset. This is usually only available by physically inspecting the chips.
So as it is defined, this object doesn't carry enough information to be useful.
The chair noted that 802.3 committee chair Geoff Thompson had suggested the use
of the 802.1F/A5 model. The chair has two problems with this: First the OUI is the
first 3 bytes of the MAC address and the chip probably cannot provide the rest of the
information. Second, there is an installed base using the current implementation. The
chair has done investigative experiments to show this. Changing the registration
process now breaks 10 years of implementation.
Jeff Johnson noted that current products from his company do return a valid value,
but he still questions the usefulness. The products have both the MAC and MAU,
and the OID is tied to both when they are really two different products.
Lynn Kubinec noted that John Flick had submitted mail to the list asserting that he has
used this object in a current product to deal with a MAC that was not operating correctly.
The chair noted that his company has also made good use of the object. Especially
during periods of transition to new technology, it is very useful.
The AD noted that IANA will deal take on the registration given that they have an
exact description of what gets registered in the name space and a contact in the
working group in case there is a question about registering
The chair wanted verification of what is necessary if method 2 (IANA registration)
- issue document saying the OIDs in RFC 2358 will be removed from that document.
- describe new method of registering chipsets with IANA
- define what an ethernet chipset is so that IANA only registers ethernet chips
- choose a contact for IANA, either the working group chair or the AD.
The chair noted that registrations can continue in the current OID name space.
Jeff Johnson noted that one submission to the mailing list suggested the enterprise name
space. The AD noted that this makes the object less useful than it currently is.
A comment was raised about whether this shouldn't be in ifDescr. The chair noted that
ifDescr is a logical level above the actual MAC. Jeff Johnson noted that ifDescr is a
string and has a non-standard format.
Another submission on the mailing list was, if this object is so useful, why is it not in
the Repeater and other MIBs? The chair noted that this may be historical. It's been a
particular problem for ethernet.
A comment was made that if this object is used during transitions, that it is perhaps only
useful for R & D and experimental purposes.
The chair concluded that the object would be removed from the MIB module and
another survey will be made of it usefulness. If the object is kept, then IANA
registration will be the method followed. Deadline for deciding is the next IETF
meetings. Gigabit ethernet was approved by the IEEE in June and it shouldn't take
more than six months to move through the IETF.
The final topic for discussion were the Ethernet-Like MIB Issues raised on the list
by the document editor, John Flick. This discussion was actually more of a review
by the chair. Comments need to be posted to the list.
I put the new objects relating to MAC Control and PAUSE into a new table, the
dot3ControlTable. Is this the way we want this structured? Should MAC
Control and PAUSE be separate tables? Or should we just keep everything in
Chair doesn't like this control table as the counters are only related to PAUSE. If a
new control function is added, then these counters don't make sense. Should have
separate tables for each control function.
dot3ControlFunctionsSupported: Is it needed, or is it redundant with
ifMauAutoNegCapability? Should it be settable (as in the IEEE doc)? If so,
what does it mean to set it? Chair's comment is that this is not redundant.
dot3ControlPauseLinkDelayAllowance: Do we need this object? I am a bit
unclear as to what it means to set this. It is not mentioned in any of the MAC
Control or PAUSE state machines.
Chair noted that this is not in the IEEE spec because during those discussions it was
thought to be too hard to implement. It turns out that this is not true, so perhaps it would
be a good think to manage.
I did not include counters for aMACControlFramesTransmitted or a
MACControlFramesReceived, since they should be derivable from individual
counters for the MAC Control functions.
Chair noted that this is rhetorical
I added dot3ControlPauseMode, which shows what the priority resolution for
PAUSE resolved to. I would rather not depend on the management app to know
how priority resolution works. Let me know if there are objections to this object.
Chair noted that it is useful information that is not in the IEEE standard.
I haven't added a DuplexMode object, since the consensus here seemed to be that
it should be in the IF-MIB. I believe Brian O'Keefe was supposed to be
submitting a proposal to the ifmib mailing list, but that hasn't happened yet. If
IF-MIB doesn't add this object, we should probably add it to this MIB. Jeff
Johnson noted that currently the IFMIB cannot be used to determine whether an
interface is operating in half duplex mode or not. There is also the question of
whether having the duplex information present in the MAU MIB is sufficient.
He noted that generic applications only look at the IFMIB to do utilization
calculation, so even if the duplex information is added to this MIB, it may not
be solving a problem.
Group consensus was that it's probably best to put the information here anyway. Note
was made that interfaces like xDSL can be full duplex and have different speeds in each
direction. This means more work for the NMS, but it is necessary.
The chair noted that the only new Gigabit related counter in the IEEE spec was the
number of burst frames and in LA the group had decided that it is probably not a
There was also a question about error counters. If the rate is greater than 640 Mbps,
then probably need High Capacity (HC) counters. The chair proposed that HC
counters not be added. The paragraph in the draft regarding relation to the IEEE
standard should mention this decision.
The charter says we need to be wrapped up by Orlando.
There was a comment about a question raised at the last working group meeting about
High Speed Token Ring. The DTR MIB was updated for 100 Mb TR and will be posted
as an informational RFC to the IETF.
The AD was asked about the SPAM problem discussed earlier. The IESG has
considered SPAM solutions. Jeff Johnson noted that it would be nice if the IETF could
provide mailing list services for all the working groups noting that both filtering and list
addressing could be provided in a consistent manner.
go to list