EFM Common MIB Issues

1
EFM Common MIB Issues
2
Common MIB or OAM MIB?

• Common MIB currently covers OAM
• Does not have anything common between EFM
  subjects
• OAM, EoCu, and EPON
• Can we just make this EFM OAM MIB?
• Wouldnt affect MIB (nothing common anyway)
• Would affect overview and introduction sections
  as theyre would be targeted differently

3
Loopback (I)

• EFM OAM Loopback is controlled via the states of
  two attributes at the local and peer OAM layer
• Multiplexer (whether higher layer traffic is
  passed down)
• Parser (identifies OAM traffic, and forwards or
  loops back other traffic)
• We have the choice to expose these primitives, or
  to go with something simpler and more abstract

4
Loopback (II)

• Simpler more abstract approach
• Replace parser/multiplexer state with loopback
  status
• dot3OamLoopbackStatus incorporates four state
  variables
• Local multiplexer state
• Local parser state
• Peer multiplexer state
• Peer parser state

5
Loopback (III)

• (From email sent to exploder with details)
• Dot3OamLoopbackEntry
• SEQUENCE
• dot3OamLoopbackCommand
  INTEGER,
• dot3OamLoopbackStatus
  INTEGER
• dot3OamLoopbackStatus OBJECT-TYPE
• SYNTAX INTEGER
• noLoopback (1),
• initiatingLoopback
  (2),
• remoteLoopback (3),
• terminatingLoopback
  (4),
• localLoopback (5),
• unknown (6)

6
Loopback (IV)

• How to map parser/multiplexer variables to
  loopback status
• The values of this attribute correspond to the
  following values of the local and remote parser
  and multiplexer states, where 'X' means the state
  can be any value.
• value LclPrsr LclMux RmtPrsr RmtMux
• noLoopback FWD FWD FWD FWD
• initLoopback DISCARD DISCARD FWD FWD
• rmtLoopback DISCARD FWD LPBK DISCARD
• tmtngLoopback DISCARD DISCARD LPBK DISCARD
• lclLoopback LPBK DISCARD DISCARD FWD
• unknown any other combination
• Pros hides the complexity of the low-level
  service primitives (easier management)
• Cons ???

7
Counters and Discontinuities

• Is guidance about counter discontinuities
  required or recommended?
• If so, is it acceptable to reference the
  ifCounterDiscontinuityTime as the key to whether
  discontinuities occurred, or do we need to create
  our own indication?
• E.g. is following text ok (for every counter)?
• Discontinuities of this counter can occur
  at
• re-initialization of the management system,
  and
• at other times as indicated by the value of
  the
• ifCounterDiscontinuityTime.

8
Event Counter Inconsistency (I)

• EFM OAM has defined events for things like frame
  error thresholds and symbol error thresholds
• EFM OAM events generally consist of
• Timestamp when did event happen
• Window size how big is the window (in time, in
  frames, whatever)
• Threshold how many things had to happen in that
  window to cause event
• Count how many things did happen in that window
• Running total how many things have happened
  since counters reinitialized?

9
Event Counter Inconsistency (II)

• Combining those two, EFM OAM events contains a
  running total of symbol errors
• There is no C30 attribute for symbol errors, so
  this is a currently unexposed/uncounted variable
• The effect is
• If events are being generated, one can access a
  counter of symbol errors
• If no events are generated, cannot access symbol
  error counter
• Seems like a strange situation to the editor that
  a basic counter is exposed in the event thats
  not in the MIB
• This ok with everyone?

10
Event Controls (I)

• EFM OAM events are generated by the OAM Client
• EFM OAM events are received by the OAM Client
• EFM OAM treats the OAM client like a black box
  (e.g. doesnt specify why it does things or when,
  only what it can do)
• Gives non-802.3 management (e.g. our MIB) the
  freedom to introduce a set of controls on OAM
  client behavior
• What kind of controls are required for handling
• When to generate events?
• What to do if receive event from peer?

11
Event Controls (II)

• Options on when to generate include
• Just have on/off for events in general
• One big switch for entire event function
• Have threshold controls but no on/off switch
• Can set thresholds high to basically disable
  event generation
• Have on/off switch and thresholds for each event
• Separate event controls for most flexibility
• Options on what to do if receive include
• Store in table
• Generate SNMP notification
• Both

12
Event Controls (III)

• Proposing the following per-event attributes to
  control when event occurs
• Event Window size
• What is window of measurement
• Threshold
• What is threshold in that window for event to
  occur
• Propose the following per-event controls for what
  to do when event occurs
• Event generation enable/disable
• Whether to generate EFM Event Notification OAMPDU
  if local event detected
• Local SNMP notification enable/disable
• Whether to generate SNMP notification if local
  event detected
• Remote SNMP notification enable/disable
• Whether to generate SNMP notification if remote
  event detected (e.g. receive EFM Event
  Notification OAMPDU from peer)