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