EFM Common MIB - issues
"Matt Squire" <[email protected]>
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
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.
===========================