Subject: [Hubmib] EFM Common MIB - issues

From: "Matt Squire" <[email-masked]>
Date: Thu, 26 Feb 2004 17:17:53 -0500

Below are some issues I'm running into when working on the next version of the EFM Common MIB.  Would appreciate any feedback.  

- Matt

=================

1) "Common" vs "OAM".  Right now, we call this MIB the EFM "common" MIB.  The idea, originally, was that this would cover anything common across all EFM PHYs.  Right now, the only thing in this MIB is OAM.  The new copper and EPON work have their own MIB.  So should we re-name/re-focus this MIB to be just OAM and not "common"?  Although the difference to the MIB section is negligible (a few name changes), I think the difference in the overview/intro section is substantial.  If "common", it needs to talk about .3ah in all its glory, and provide an overview of OAM/copper/PON.  If "OAM", that goes away and its a relatively focused overview/intro.

======================

2) Loopback.  I'd like to go to a loopback control that looks like 
       Dot3OamLoopbackEntry ::=
           SEQUENCE {
               dot3OamLoopbackCommand            INTEGER,
               dot3OamLoopbackStatus             INTEGER
           }
Where you can issue a loopback command with the first entry, and the second entry gives a loopoback state.  The difficulty/benefit of the loopback status variable is that in OAM and C30, we expose the local/remote multiplexor/parser state, but there's no simple loopback status.  It seems more beneficial from a management status to provide something simpler than exposing parser/mux status on each end of the link.  So here's what I'm thinking, and I'd appreciate thoughts if its acceptable to try to simplify the interface like this, or of people would rather have the parser/mux states available and let the user figure out how that relates to a good loopback operation.  

       dot3OamLoopbackStatus OBJECT-TYPE
           SYNTAX      INTEGER { 
                           noLoopback (1), 
                           initiatingLoopback (2),
                           remoteLoopback (3),
                           terminatingLoopback (4),
                           localLoopback (5),
			         unknown (6)
                       } 
           MAX-ACCESS  read-only 
           STATUS      current 
           DESCRIPTION "The loopback status of the OAM entity.  This 
		       status is determined by a combination of the
		       local parser and multiplexer states, the remote
		       parser and multiplexer states, as well as
		       by the actions of the local OAM client.  When
		       operating in normal mode with no loopback in
		       progress, the status reads noLoopback(1).  
                       
                   If the OAM client has sent an OAM loopback PDU
                   and is waiting for a response, where the local
                   parser and multiplexer states are DISCARD (see
                   [802.3ah, 57.2.11.1]), the status is 
                   'initiatingLoopback'.  In this case, the local
		       OAM entity has yet to receive any
		       acknowledgement that the remote OAM entity has
		       received its loopback command request.  
                       
		       If the local OAM client knows that the remote
		       OAM entity is in loopback mode (via the remote
		       state information as described in [802.3ah,
		       57.2.11.1, 30.11.1.1.15]), the status is
		       remoteLoopback(3).  If the local OAM client is
		       in the process of terminating the remote
		       loopback [802.3ah, 57.2.11.3, 30.11.1.1.14],
		       with its local multiplexer and parser states in
		       DISCARD, the status is terminatingLoopback(4).
		       If the remote OAM client has put the local OAM
		       entity in loopback mode as indicated by its
		       local parser state, the status is
		       localLoopback(5).  

		       The unknown(6) status indicates the parser and
		       multiplexer combination is unexpected.  This
		       status may be returned if the OAM loopback is
		       in a transition state but should not persist.  

		       The values of this attribute correspond to the
		       following values of the local and remote paser
		       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 **
                       " 
           REFERENCE   "[802.3ah], REFERENCE 57.2.11, 30.11.1.1.14,
	               30.11.1.1.15"   
           ::= { dot3OamLoopbackEntry 2 }

=======================

3) Counters.  For all of the counters, do we have to (or just should we) always include some text reference on discontinuities, and if so, can we just reference the ifCounterDiscontinuityTime or do we need something else.  For example, is the following text sufficient/good for each 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.  

=========================

4) Event counters exposure.  As has been discussed a little on the list, Events can expose information thats not always there, and its kind of funky.  The primary example is symbol errors.  There is not Ethernet counter for symbol errors.  However, we have events that trigger on symbol errors, and if the event occurs, the number of symbol errors that have occurred *at the time of the event* is available.  So its a counter, but its a snapshot view.  

===========================

5) Event Control. I had received a suggestion to have more control on events (e.g. be able to turn them on/off).  Such controls don't exist in C30.  However, the issueing of events happens architecturally within the OAM client, which is sort of a black box and not specified within the document.  So I'd like to add controls for each event to (a) if that event occurs, send an Event Notification OAMPDU, (b) if that event occurs, send a SNMP notification, and (c) if that event is received from the OAM peer, send a SNMP notification.  I'm thinking about attributes like the following (below is for Errored Symbol Events, but this applies to other events too):  

       dot3OamErrSymPeriodWindow OBJECT-TYPE
           SYNTAX      Unsigned32
           MAX-ACCESS  read-write
           STATUS      current
           DESCRIPTION "The number of symbols over which the 
                       threshold is defined.  
                       
                       If dot3OamErrSymPeriodThreshold symbol errors
                       occur within a window of
                       dot3OamErrSymPeriodWindow symbols, an Event
                       Notification OAMPDU should be generated with an
                       Errored Symbol Period Event TLV indicating the
                       threshold has been crossed in this window.  
                       "
           REFERENCE   "[802.3ah], 30.11.1.1.34"  
           ::= { dot3OamEventConfigEntry 1 }
     
       dot3OamErrSymPeriodThreshold OBJECT-TYPE
           SYNTAX      Unsigned32
           MAX-ACCESS  read-write
           STATUS      current
           DESCRIPTION "The number of symbols errors that must occur 
                        for this event to be triggered.  
                          
                       If dot3OamErrSymPeriodThreshold symbol errors
                       occur within a window of
                       dot3OamErrSymPeriodWindow symbols, an Event
                       Notification OAMPDU should be generated with an
                       Errored Symbol Period Event TLV indicating the
                       threshold has been crossed in this window.  
                       "
           REFERENCE   "[802.3ah], 30.11.1.1.34"  
           ::= { dot3OamEventConfigEntry 2 }

       dot3OamErrSymPeriodEvNotifEnable OBJECT-TYPE 
           SYNTAX      INTEGER { enabled(1), disabled(2) }
           MAX-ACCESS  read-write
           STATUS      current
           DESCRIPTION "Indicates whether the occurence of Errored Symbol 
                       Period Events should result in Event
                       Notification OAMPDUs generated by the OAM layer.  
                       
                       By default, this object should have the value
                       enabled(1) for Ethernet like interfaces that
                       support OAM.  If the OAM layer does not support
                       event notifications (as indicated via the
                       dot3OamFunctionsSupported attribute), this
                       value is ignored.  
                       "
           REFERENCE   "N/A"  
           ::= { dot3OamEventConfigEntry 3 }
           
       dot3OamErrSymPeriodLclTrapEnable OBJECT-TYPE 
           SYNTAX      INTEGER { enabled(1), disabled(2) }
           MAX-ACCESS  read-write
           STATUS      current
           DESCRIPTION "Indicates whether the occurence of Errored Symbol 
                       Period Events should result in SNMP traps. 
                       
                       By default, this object should have the value
                       disabled(1) for Ethernet like interfaces that
                       support OAM.  If the OAM layer does not support
                       event notifications (as indicated via the
                       dot3OamFunctionsSupported attribute), this
                       value is ignored.  
                       "
           REFERENCE   "N/A"  
           ::= { dot3OamEventConfigEntry 4 }
           
       dot3OamErrSymPeriodRmtTrapEnable OBJECT-TYPE 
           SYNTAX      INTEGER { enabled(1), disabled(2) }
           MAX-ACCESS  read-write
           STATUS      current
           DESCRIPTION "Indicates whether the reception of Errored 
                       Symbol Period event from an OAM peer should 
                       result in an SNMP trap. 
                       
                       By default, this object should have the value
                       disabled(1) for Ethernet like interfaces that
                       support OAM.  If the OAM layer does not support
                       event notifications (as indicated via the
                       dot3OamFunctionsSupported attribute), this
                       value is ignored.  
                       "
           REFERENCE   "N/A"  
           ::= { dot3OamEventConfigEntry 5 }

The idea being you can set threshold that define "when something bad" happens.  Then you have additional control that define what you do about it - e.g. send OAM events, send SNMP notifications, etc.  

===========================

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib