1 / 14

Update on EFM OAM MIB draft-ietf-hubmib-efm-mib-01.txt

Update on EFM OAM MIB draft-ietf-hubmib-efm-mib-01.txt. Matt Squire Hatteras Networks. Differences from –00 General. Much of the draft has changed General reasons for change Updated objects & references from D3.0/D3.1 to D3.3

brendalee
Télécharger la présentation

Update on EFM OAM MIB draft-ietf-hubmib-efm-mib-01.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Update on EFM OAM MIBdraft-ietf-hubmib-efm-mib-01.txt Matt Squire Hatteras Networks

  2. 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

  3. EFM Common MIB dot3OamMIB dot3OamTable dot3OamStatsTable dot3OamPeerTable dot3OamLoopbackTable dot3OamEventConfigTable EFM OAM MIB dot3OamMIB dot3OamTable dot3OamPeerTable dot3OamLoopbackTable dot3OamStatsTable dot3OamEventConfigTable dot3OamEventStatusTable dot3OamTraps Differences from –00Structure

  4. dot3OamCompliance dot3OamControlGroup dot3OamStatsGroup dot3OamLoopbackGroup dot3Oam<eventType>Group dot3OamCompliance dot3OamControlGroup dot3OamStatsGroup dot3OamLoopbackGroup dot3Oam<eventType>Group Differences from –00Structure

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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.

  11. 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?

  12. 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.)

  13. 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?

  14. 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?

More Related