140 likes | 155 Views
Draft version with improved object descriptions, added functionality, and enhanced event handling in EFM OAM MIB. Changes from previous versions explained, including updated tables and structures for better monitoring capabilities.
E N D
Update on EFM OAM MIBdraft-ietf-hubmib-efm-mib-01.txt Matt Squire Hatteras Networks
Differences from –00General • Much of the draft has changed • General reasons for change • Updated objects & references from D3.0/D3.1 to D3.3 • Improved and enhanced descriptions of objects to improve readability and understanding • Add more functionality and fill in previously identified holes (e.g. event handling) • This is the first functionally complete draft version
EFM Common MIB dot3OamMIB dot3OamTable dot3OamStatsTable dot3OamPeerTable dot3OamLoopbackTable dot3OamEventConfigTable EFM OAM MIB dot3OamMIB dot3OamTable dot3OamPeerTable dot3OamLoopbackTable dot3OamStatsTable dot3OamEventConfigTable dot3OamEventStatusTable dot3OamTraps Differences from –00Structure
dot3OamCompliance dot3OamControlGroup dot3OamStatsGroup dot3OamLoopbackGroup dot3Oam<eventType>Group dot3OamCompliance dot3OamControlGroup dot3OamStatsGroup dot3OamLoopbackGroup dot3Oam<eventType>Group Differences from –00Structure
Differences from –00dot3OamTable, dot3OamPeerTable • dot3OamTable • Added new OperStatus (link fault state) • Result of changes in D/3.2 • dot3OamPeerTable • Removed information on state of remote multiplexer and parser • Implicitly included in the dot3OamLoopbackTable • Added additional details on when various objects change
Differences from –00dot3OamLoopbackTable, dot3OamStatsTable • dot3OamLoopbackTable • Added object to control whether local station should listen to received loopback commands • dot3OamStatsTable • Updated to D3.3 stats (event counters, unsupported op codes, frames lost due to OAM) • Removed total OAMPDUs transmitted and received • These can be derived
Differences from –00dot3OamEventConfigTable, dot3OamEventStatusTable • dot3OamEventConfigTable • Added enable/disable for each event to control whether local station monitors for that event • dot3OamEventStatusTable (new) • Maintains information on latest event of each type on the local and peer entity • For each event, keep • timestamp (when it happened) and • OAM Event TLV data • Moved flags (which are indicators of specific events) from dot3OamTable/dot3OamPeerTable to here
Differences from –00dot3OamTraps • dot3OamTraps • Added set of notifications • For each event (6 of them), have notification type defined for event happening on local or remote system (12 notifications) • Notification information includes entire Event TLV identifying information
Differences from –00Other • Security • Enhanced security section, loopback risks • Overview/Intro • Added MIB overview, relation to other MIBs, including mapping of 802.3 C30 attributes to SNMP objects • References • New • Acknowledgements • New
Open Issues (1) • Relationships to other MIBs • Is this an OAM MIB, or an overview of EFM? • How much information on EPON, EFMCu, and other EFM is required? • Note that in the last review cycle, it was decided to make this an “EFM OAM” MIB instead of an “EFM Common” MIB. • Preference is to not change this back to a general overview/common. • Row status • Is row status needed in dot3OamTable and dot3OamPeerTable, or just agent managed? • Currently, they have a row status, but they are automatically created by agent based on support of OAM and discovery of peer • Preference is to remove the row status from each table.
Open Issues (2) • EPON • Question has been asked if anything special is required for EPON? • dot3OamPeerTable allows one peer per ifIndex • With p2mp of EPON, do we need multiple peers per ifIndex? • EPON has a p2p emulation table • Makes one EPON interface with split of N look like N Ethernet interfaces • OAM (like any other protocol above the MAC) needs to be based on the p2p emulation • Preference would be to not say anything special about EPON • OAM is no different than other protocols • Does every protocol have to say something special about EPON, or does EPON simply say how to handle everything?
Open Issues (3) • Controlling loopback • Loopback is an intrusive operation • Data path goes down while loopback tests go on • With EFM OAM, as long as peer is in active mode, it can issue loopback command to local OAM client • Added dot3OamLoopbackIgnoreRx to latest draft • Adds control so that management can control whether loopback is allowed • Does dot3OamLoopbackIgnoreRx help/hurt? • Assuming it’s a good thing, • What default for passive mode? Active mode? • Should we have similar “ignore” objects for other functions (variable retrieval, event reception, etc.)
Open Issues (4) • Event configuration • Events currently configured with threshold, window, enable objects • Events can be sent multiple times because not reliable • Do we need a configurable number of retries? • Not clear that all implementations would support it • Event status table • Currently store the entire TLV as octet array • Is this ok? • All non-standard TLVs share a single row • Should we expand/extend that to allow multiple?
Open Issues (5) • Compliance • Currently have different conformance groups for every event type • Allows some events to be implemented, some not • Could put events as single conformance group?