NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98
Chair(s):
Dan Romascanu <dromasca@madge.com>
Operations and Management Area Director(s):
John Curran <jcurran@bbn.com>
Michael O'Dell <mo@uu.net>
Operations and Management Area Advisor:
John Curran <jcurran@bbn.com>
Mailing Lists:
General Discussion:hubmib@hprnd.rose.hp.com
To Subscribe: hubmib-request@hprnd.rose.hp.com
Archive: ftp://ftp.rose.hp.com/pub/hubmib
Description of Working Group:
This working group will produce a document describing MIB objects for use in managing Ethernet-like hubs. A hub is defined as a multiport repeater that conforms to Section 9, ``Repeater Unit for 10 Mb/s Baseband Networks'' in the IEEE 802.3/ISO 8802-3 CSMA/CD standard (2nd edition, Sept. 1990). These hub MIB objects may be used to manage non-standard repeater-like devices, but defining objects to describe vendor-specific properties of non-standard repeater-like devices is outside the scope of this working group. The MIB object definitions produced will be for use by SNMP and will be consistent with other SNMP objects, conventions, and definitions.
In order to minimize the instrumentation burden on managed agents, the MIB definitions produced by the working group will wherever feasible be semantically consistent with the managed objects defined in the IEEE Standard 802.3u, Section 30, "10 Mb / s & 100 Mb / s Management".
The working group will produce a document describing MIB objects for use in management of connectivity boxes that include Ethernet ports with a behavior consistent to the repeater ports defined by the 802.3 Standards. The repeater ports will be mapped to the internal box structure that may include one or more repeater units that conform to the IEEE 802.3/ISO 8802-3 CSMA/CD standard. If so, all instrumentation variables will be backward compatible with the existing hardware implementations that comply to the IEEE 802.3 repeaters.
The mapping model defined by this MIB module may be used by other type of non-802.3 units (e.g. 802.12 repeaters) to map their own port management objects to the multiple repeaters inside a connectivity box.
Consistent with the IETF policy regarding the treatment of MIB definitions produced by other standards bodies, the working group may choose to consider only a subset of those objects in the IEEE specification and is under no obligation to consider (even for ``Optional'' status) all objects defined in the IEEE specification. Moreover, when justified by special operational needs of the community, the Working Group may choose to define additional MIB objects that are not present in the IEEE specification.
Although the definitions produced by the working group should be architecturally consistent with MIB-II and related MIBs wherever possible, the charter of the working group does not extend to perturbing the conceptual models implicit in MIB-II or related MIBs in order to accommodate 802.3 hubs. In particular, to the extent that the notion of a ``port'' in an 802.3 hub is not consistent with the notion of a network ``interface'' as articulated in MIB-II, it shall be modeled independently by objects defined in the working group.
Because the structure of 802.3 hub implementations varies widely, the working group shall take special care that its definitions reflect a generic and consistent architectural model of hub management rather than the structure of particular hub implementations.
The IEEE hub Management draft allows an implementor to separate the ports in a hub into groups, if desired (i.e., a vendor might choose to represent field-replaceable units as groups of ports so that the port numbering would match a modular hardware implementation). Because the working group charter does not extend to consideration of fault-tolerant, highly-available systems in general, its treatment of these groups of ports in an 802.3 hub (if any) shall be specific to hub management and without impact upon other portions of the MIB.
The working group is further chartered at its discretion to define an SNMP MIB for management of IEEE 802.3 Medium Access Units (MAUs). An 802.3 Medium Attachment Unit (MAU) attaches a repeater port or Ethernet-like interface to the local network medium. The scope of this work may include several types of MAU units: 10BASE-5 (thick coax), 10BASE-2 (thin coax), 10BASE-T (twisted pair), FOIRL and 10BASE-F (fiber optic). Managed objects defined as part of the MAU MIB task may, for example, represent such information as MAU type, link status, and jabbering indications.
The working group is further chartered to define an SNMP MIB for the management of the 100Base-T hubs, MAUs and interfaces, or to propose additions / changes to existing MIB modules that deal with IEEE 802.3 hubs, MAUs or interfaces in order to extend their support to 100Base-T. In case when those MIB modules are the result of the work of another working group in the NM Area, the proposal will be submitted to the directorate and the respective WG.
Goals and Milestones:
Done |
|
Submit the Media Access Unit MIB to the IESG for consideration as a Proposed Standard. |
Done |
|
Submit the Repeater MIB to the IESG for consideration as a Proposed Standard. |
Done |
|
Review all documents at IETF meeting. Hopefully recommend advancement with specified editing changes. |
Done |
|
Documents available with specified changes incorporated. |
Done |
|
Distribute updated documents for more E-mail discussion. |
Done |
|
Post the Media Access Unit MIB Definition as an Internet-Draft. |
Jul 95 |
|
Meet at 33rd IETF to review all WG RFCs to ascertain if ready for advancement on the standards track. |
Nov 95 |
|
Submit new Repeater MIB, MAU MIB as Internet-Drafts. |
Dec 95 |
|
Meet at 34th IETF to review Internet-Drafts and make necessary changes to existing RFCs. |
Mar 96 |
|
Meet at 35th IETF (LA) to finalize changes. |
Apr 96 |
|
Submit new MIB modules to the IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· Definitions of Managed Objects for the Ethernet-like Interface Types
Request For Comments:
RFC |
Status |
Title |
RFC1515 |
PS |
Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) |
RFC2108 |
PS |
Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 |
RFC2239 |
PS |
Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2 |
Minutes of the IEEE 802.3 Hub MIB (hubmib) Working Group
Reported by John Flick (johnf@rose.hp.com)
The meeting began with administrative info and agenda bashing. The agenda was accepted as presented.
The chair asked if there were any last minute problems that would prevent the current draft of the Ether-like interface MIB from being advanced to Proposed Standard. There were none.
The chair then initiated a discussion of how best to handle gathering implementation experience for RFC 2108 and RFC 2239. He pointed out that during the last round, a questionnaire was issued, and the results were compiled by an independent party who did not work for a hub or switch vendor. He asked how many people in the room had implementation reports for these RFCs. Five people raised their hands. He next asked if any of those people would have a problem with sending those reports to an individual who works for a repeater or switch vendor. No one felt that this would be a problem. The working group agreed to try to put together implementation reports by June.
Next, we looked at the status of recent and current efforts in the IEEE that may potentially affect this working group.
· IEEE 802.3-1996 and 802.3u are currently covered by our RFCs and the Ether-like draft that is in IESG last call.
· 802.3x and 802.3y approved 11/97. Not currently covered by our work. Covers 100BASE-T2 and full-duplex Ethernet, including flow control.
· 802.3z ballot closed 1/98. Covers Gigabit Ethernet. Currently doing sponsor ballot recirculation. Not currently covered by our work.
· 802.3ab covers 1000BASE-T. All management-related issues are covered in 802.3z.
· 802.3ac WG recirculation ballot closed 3/98. Covers changes for VLANs, including changing the definition of max-packet.
· Trunking study group - may affect us and IFMIB, but this work is currently in the very early stages. Too early for us to consider at this time.
Howard Frazier, chair of 802.3z, indicated that 802.3z should be completed by June. Also pointed out that any changes to management needed by 802.3ab have already been anticipated in 802.3z. When asked, 802.3 chair Geoff Thompson indicated that clause 30 of 802.3z has the most up-to-date management information for 802.3.
The issue was raised of how we are affected by the change to max-packet in 802.3ac. The concern was that a management station can't tell whether an agent is incrementing that counter at 1519 bytes or at 1523 bytes. This is a potential interoperability problem. It was suggested that we should add an object that indicates what that agent considers to be an oversize packet. A similar thing was done in the DataSourceCapabilities table in SMON. It was pointed out that with max-packet at 1522, an oversize frame less than 1523 bytes long that does not contain a VLAN header is still an error, but is not counted as one. It was felt that it wasn't worth the extra expense of requiring the agent to examine the header to determine if a tag was present before incrementing this counter.
We discussed some ideas for how this working group can maintain closer contact with IEEE 802.3. We can encourage members of 802.3 to join our mailing list, encourage members of this working group to join the 802.3 mail reflector. Howard Frazier indicated that he had no problem with providing members of this working group with the password to access the 802.3z web site to get updated copies of their document. WG members can either contact him (hfrazier@cisco.com) or Geoff Thompson (geoff_thompson@baynetworks.com) for access information.
Andrew Smith then gave a presentation about changes to the MAU MIB needed for 802.3x and 802.3z support. There are no new objects needed, but it does need new OIDs, bit values, and enumerations. In addition, several DESCRIPTION clauses need to be updated to include mention of gigabit.
We determined that we need to add new MAU types for the various flavors of Gigabit Ethernet MAUs for both half and full duplex. We decided that we do not need MAU types for unknown duplex. However, we do need MAU types for unknown PMD, since there is no standard way to identify the PMD in the IEEE standard.
We decided to deprecate the ifMauTypeList object. This object was defined as an Integer32, and we now need more than 32 bits. It should have been defined as BITS, and we decided to deprecate the old object and define a new one of type BITS.
We need to extend the enumerations for ifMauAutoNegStatus to include new status values defined in 802.3x.
We need to add new bit definitions for ifMauAutoNegAdvertizedCaps, ifMauAutoNegCapabilities, and ifMauAutoNegReceivedCaps for the new MAU types and for PAUSE negotiation. Decided that we should also deprecate these objects and define new ones of type BITS.
For FAULT negotiation, we decided that instead of packing these into the ifMauAutoNeg* BITS objects, we would define a separate enumerated integer object. There was some discussion about whether the corresponding bits in the ifMauAutoNeg* BITS objects should be marked as reserved. Deferred to the mailing list.
John Flick then presented changes needed to the Ether-like Interface MIB for Gigabit and flow control support. There was some discussion about whether counters that are not used in full-duplex mode should cease to exist when the interface is in full-duplex mode, or should just not increment. In the past, we have just said that those objects should retain there values and not increment when the interface is in a mode where they are unused. The IEEE documents state that their values are undefined in this case. There was considerable debate, with one camp arguing that they should just retain their value to avoid the discontinuity, and another saying that loss-of-link should always be considered a possible discontinuity. The conclusion seemed to be that we should just state that they should not increment, but we need to be careful to word this such that it is clear that this behavior is different from that defined by IEEE. The alternative was felt to be too much of a semantic change to the existing counters. Final decision deferred to the mailing list.
John then proposed some additional counters for flow control instrumentation. These counters were proposed in 802.3x, but as rather late ballot comments. The concern there was that they did not fit the 802.3x layering model, and it was too late in the process to fix it. There was considerable concern expressed about adding counters that required hardware instrumentation not specified in the IEEE spec. Also, some present felt that if the PAUSE frame counters were incrementing at all that this indicated that congestion was occurring, and this was sufficient. Discussion was deferred to the mailing list.
The chair then asked if we wanted to tackle Gigabit Repeater management at this time. It was felt that it would be simple to do, but why? There do not appear to be any implementations in the market or in development. Decided this work can be deferred. It was felt that no new work is needed on the Repeater MIB, unless something shows up as a result of the implementation experience and interoperability reports.
We then discussed logistics for the updates to the Ether-like and MAU MIBs. Should we change the current document, or try to keep the changes in a separate document so the current documents can advance to Draft. It was felt that separating the new stuff would be awkward. The feeling was that getting the MIB objects right was more important than advancing to Draft. We decided that discussing this was premature. We need to get implementation reports for the current documents before we can determine if advancing the current documents is even an option.
We next moved on to a discussion of the charter updates needed for this new work. Dan proposed changing the working group name to reflect the fact that we are working on more than just hubs. Dave Perkins suggested changing it to cover 802 LANs, in particular, Token Ring. It was pointed out that IEEE 802.5 is already doing their MIBs in SMIv2 format instead of GDMO, so there is less need for a working group in IETF for 802.5 management. In addition, there is little commonality between the new 802.3 and 802.5 work. When asked whether there were any 802.5 experts in the room, no one raised their hands. The suggestion was withdrawn.
Steve Owen volunteered to contact the chairs of the IEEE 802.5 Committee and see if they are interested in coordinating with this WG or some other WG in the IETF.
We agreed that we would like the new name of the WG to be 'IEEE 802.3 Interfaces and Hub MIB WG", and we would like to modify the description of the working group to read:
· 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.
The following schedule was presented and agreed to:
· April-June 1998 Gather implementation feedback on RFC 2108 and RFC 2239
· June 1998 Post internet-drafts for Full Duplex and Gigabit Ethernet MIB extensions
· August 1998 Meet at 42nd IETF to discuss internet-drafts and implementation feedback
· September 1998 Post revised internet-drafts
· October 1998 Working Group last call
· November 1998 Submit internet-drafts to IESG for consideration as Proposed Standards
HUBMIB - Agenda and Charter Proposal
Ether-like Interfaces MIB
Gigabit MAU MIB Extensions to RFC2239