Last Modified: 2004-06-07
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.
| 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 |
| RFC | Status | Title |
|---|---|---|
| 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 |
| RFC3621 | Standard | Power Ethernet MIB |
|
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. Issues: 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 |