RE: EFM Common MIB - issues
Edward Beili <[email protected]>
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
Matt, 1) I support the name change from EFM-COMMON-MIB to EFM-OAM-MIB. The overview section is not worth it. The current name is misleading since an EPON or EFMCu equipment manufacturer doesn't have to implement this MIB unless an OAM functionality is supported. Regards, -Edward > -----Original Message----- > From: Matt Squire [mailto:[email protected]] > Sent: Friday, February 27, 2004 12:18 AM > To: [email protected] > Cc: Dan Romascanu (Dan) (E-mail) > Subject: [Hubmib] EFM Common MIB - issues > > > > 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 protected] > https://www1.ietf.org/mailman/listinfo/hubmib >