2.4.8 Ethernet Interfaces and Hub MIB (hubmib)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-07

Dan Romascanu <dromasca@avaya.com>
Operations and Management Area Director(s):
Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Mailing Lists:
General Discussion: hubmib@ietf.org
To Subscribe: hubmib-request@ietf.org
In Body: subscribe your_email_address
Archive: http://www.ietf.org/mail-archive/web/hubmib/index.html
Description of Working Group:
The Ethernet Interfaces and Hub MIB WG is Chartered to define a set of managed objects that instrument devices, MAUs and 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.

Close coordination with hardware standards development in IEEE 802.3 will be followed. The WG chair will support the communication with IEEE 802.3. When objects are added that require hardware support, IEEE 802.3 shall be informed, so that they consider to add them to their draft/standard.

The MIB object definitions produced will be for use by SNMP and will be adequately consistent with other SNMP objects, standards and conventions.

The working group will work on the following MIB modules for the IEEE 802.3ah (Ethernet First Mile) interfaces and devices:

- Ethernet First Mile (EFM) MIB common attributes, OAM operations and statistics

- Copper EFM MIB

- Ethernet Passive Optical Networks (EPON) MIB

The base for the definition of the managed objects in these MIB modules will be the management-related clauses in IEEE 802.3ah specification. The working group will also take into consideration management objects defined by other Working Groups in the IETF (ADSL MIB for example), or other standard bodies (G.983.2), will avoid work duplication, and describe the relationship with these specifications.

Goals and Milestones:
Done  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
Done  Gather implementation experience feedback concerning RFC 2108 and RFC 2239
Done  Post Internet-Draft(s) for Full Duplex and 1 Gigabit Ethernet MIB extensions
Done  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
Done  Post revised Internet-Draft(s)
Done  Conduct WG Last Call on Internet-Draft(s)
Done  Submit final version of the Internet-Draft(s) to the IESG for consideration as Proposed Standards
Done  Submit revised version of the Internet-Drafts, following the Area Directorate review
Done  Submit final versions of the MAU MIB and Ethernet-like Interfaces MIB Internet-Draft(s) to the IESG for consideration as Proposed Standards
Done  Submit the Ethernet Chipsets document to IESG for consideration as an Informational RFC
Done  Begin identifying new work items for future work
Done  Issue WG Drafts for MIBs for P802.3ae & P802.3af
Done  Issue revised WG Drafts for MIBs for P802.3ae/P802.3af
Done  Gather implementation experience concerning WG documents already on the standards track
Done  WG Last Call All documents
Done  Issue revised WG drafts for existing stds track documents if so required by the implementation reports
Done  Forward Internet-Drafts to the AD/IESG Stds track considerations
Done  Power Ethernet MIB Last Call
Done  Submit Power Ethernet MIB to AD/IESG for Standards track consideration
Done  Individual submissions for the EFM MIB modules
Done  First round of WG Internet-Drafts for the EFM MIB modules
Apr 04  Working Group Last Call
Jun 04  Submit the Internet-Drafts to the IESG for consideration as Proposed Standards
  • - draft-ietf-hubmib-efm-epon-mib-01.txt
  • - draft-ietf-hubmib-efm-cu-mib-01.txt
  • - draft-ietf-hubmib-efm-mib-01.txt
  • Request For Comments:
    RFC1368 PS Definitions of Managed Objects for IEEE 802.3 Repeater Devices
    RFC1516 DS Definitions of Managed Objects for IEEE 802.3 Repeater Devices
    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
    RFC2358 PS Definitions of Managed Objects for the Ethernet-like Interface Types
    RFC2665 PS Definitions of Managed Objects for the Ethernet-like Interface Types
    RFC2666 I Definitions of Object Identifiers for Identifying Ethernet Chip Sets
    RFC2668 PS Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2
    RFC3635 PS Definitions of Managed Objects for the Ethernet-like Interface Types
    RFC3637 PS Definition of Managed Objects for the Ethernet WAN Interface Sublayer
    RFC3636 PS Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)
    RFC3638 I Applicability Statement for Reclassification of RFC 1643 to Historic Status
    RFC3621StandardPower Ethernet MIB

    Current Meeting Report

    IETF60 - HUBMIB Minutes (Draft)
    General/Intro - Dan Romascanu
    .3ah recently was finalized, but not yet publicized. The IDs of this group are out in last call, but still have many comments. Therefore, it is likely we'll have to change the current schedule. Ideally, the authors will put out another last call by early September timeframe (current last call ends 8/15). Hoping that hubmib will not meet at the next IETF meeting.
    There is a question as to handle the new Ethernet physical layers and the MAU MIB. General idea is to pull the MAU type information into an IANA registry. To do so, we'd have to pull the MAU types and descriptions out of the MAU MIB and into a registry. General feel of the room was that this is a good thing. Will be brought up on the list. EdB volunteered to edit this work item. IETF is recommending to the IEEE that it take on its own MIB work. 802.1 has been doing a good job recently, 802.3 hasn't taken the steps. Needs to be prodded along further.
    OAM MIB - Matt Squire

    1) Relationship to other MIBs. There was a comment to add more verbiage on the entirety of the EFM project to this MIB. After a little discussion, it seemed like the consensus would be to add some text in the overview/background sections, but do not include anything in the actual MIB itself.
    2) Row status. There were several tables with row status (dot3OamTable, dot3OamPeerTable). This was commented as unnecessary and will be removed while adding an inactive state object.
    3) Special stuff for EPON. A question was asked if anything special is needed for using OAM on EPON. In general, EPON looks like a collection of p2p links to higher layer applications, OAM included but not special in that regard. The suggestion at the end was to add a brief sentence somewhere that indicates EPON has an architecture for higher layer applications like OAM, reference the EPON MIB, but not go into any detail here.
    4) Loopback control. A comment was made that the OAM loopback control isn't secure. In the end, the commenter misunderstood the intent/workings of the OAM loopback control objects and withdrew the comment after some discussion. It was decided that OAM should not allow loopback commands from the peer by default (dot3OamLoopbackIgnoreRx=true by default).
    5) Event configuration. A question was raised as to whether OAM should have a configurable number of re-tries for the event replication. The idea would be to allow the administrator to configure whether an event should be sent once, twice, etc., in order to control the tradeoff between utilization and reliability (as OAM events are not confirmed or guaranteed). Some discussion but no consensus, so if you have an opinion, pass it on. If no proposals show up, the current scheme remains as is.
    6) Event status table. Currently, event information is stored as a TLV (e.g. an octet array). The individual field are not pulled out and exposed. A question was raised as to whether this is good or bad. The positive aspects are that it results in fewer fields, but on the other side, the fields are probably useful and need to be exposed for a manager. There seemed to be consensus that the fields should be pulled out of the TLV. And that we might be able to create a generic event table rather than one row per event type.
    7) Event compliance. There was a question as to whether the compliance table should require implementation of all events, or if each event can be its own compliance group. The justification for individual compliance groups for different events are that some can be implemented easier than others (e.g. remote fault may require hardware changes, frame error thresholds would not). So the general feeling seemed to be that we can keep the individual event compliance groups, with better explanation of the motivation in the text.

    EPON MIB - Lior Khermosh
    General changes had to do with aligning the ID with D3.3 of EFM. Still MIB compiling issues (editorial, mostly worked out) that need to be finished. Also added relations to the current MIBs (epon, optics, bridge, etc.) to better clarify relationships among entities.
    Another change is that the EPON MIBs have been partitioned into
    1) control
    2) stats
    3) LLID Mac addresses
    4) events
    5) event logs
    for simpler understanding/logic.
    Also added to this revision is that more event information has been added - event state, event enable, event logs.
    Finally, removed overlap with OAM MIB.

    1) There were some font problems. Will be fixed.
    2) MAU changes. Suggested changes to MAU as talked about earlier (separate IANA controlled registry).
    3) How is dot3MpcpId determined/set? Currently unclear in draft, needs better description.
    4) Admin state looks like an oper state? Which do you mean? Note the EFM doc consistently (mpcp, oam, flow control) uses AdminControl to change admin state, and makes AdminState read-only.
    4) Device separation. This came up in the context of some counters, but generally the MIB needs to better define which objects are applicable to ONU, OLT, both, etc. Its not clear in the current draft.
    5) In general, need to clearly define what units used, how units represented, possible values, etc. Theme shows up in several comments against the draft (e.g. eponDeviceObjctReportThreshold).
    6) Need to specify that eponDeviceRemoteMacAddressLLDTable can be erased on a re-set, and in general, the description needs to be improved (hard to understand).
    7) eponDeviceEventsLogTable is not described well. The intent is a MAC level event log (set of events to when they happened). A question was asked if this is useful (some thought it would be). Another question on whether it would be better/useful if OAM had one, and/or if they shared a common event log.

    EFMCu MIB - Ed Beili
    Changes from draft -00 include
    - Some restructuring of tables, map to D3.3 better.
    - Available stack table - r/o, system sets is abilities
    - Added target bandwidth, target SNR margin
    - Added profile table
    - New notifications (low bandwidth), enable/disable each notification

    Open issues:
    1) Relation to shds/vdsl MIBs. At previous meeting, decided to NOT import other MIBs but to duplicate where needed. Many reasons
    - many not available in .3ah
    - simpler , name consistency
    - unifies 2b/10p as much as possible
    - ieee is a frozen set of ITU capabilties
    Some in room agreed, but needs to go to the list to discuss further.
    2) efmCuAvaialbeStackTable describes x-connect capability (read-only) - should it be generalized/moved into its own thing? This is common with (possibly) ITU and ANSI work in progress? Consensus was to re-name it to appear more generic (e.g. ifAvailableStackTable) but to keep it in the current EFMCu MIB.
    3) Notifications - currently have a few, could add more - errored seconds, ses, uas, ...
    VDSL/SHDSL MIBs have more, but they're relatively unused in practice. Can we not copy that model? Hope is yes, but take it to the list.
    4) ifSpeed - what should it be (aggregate & PME)? There are some concerns/questions on what the ifSpeed of the interface should be. Most Etehrnet PHYs use "net data rate of the MII". This includes frames, preamble, ipg, etc. Preamble, IPG aren't carried on EFMCu, 64/65 overhead and bonding overhead may be added. So there's an open question on how to set ifSpeed and if we need anything else. Thought was to contact IEEE (via mailing lists) to get their opinion. Generaly doesn't feel right to say EFMCus are all 100Mbps because thats what the MAC is running at. Take it to the list (TITTL)...
    5) Target SNR margin overlooked in .3ah, seems like we should keep it, question whether it should be stored in the profile or if we should store it at the PCS or at the PME or something else? TITTL...
    6) C30 deficiencies. Do we need to take a position on addressing C30 deficiencies? Its missing many (?) expected objects for control, and we're directly referencing C45 registers instead of C30 attributes. Will take to mailing list to determine if enough people agree things need to be added to C30 to address deficiencies. TITTLL...Notes taken by Matt Squire and Dan Romascanu


    Update on EFM OAM MIB