[Hubmib] Response to comments on OAM doc
"David T. Perkins" <dperkins@dsperkins.com> Sun, 22 January 2006 06:05 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0YLg-0003Rj-MT; Sun, 22 Jan 2006 01:05:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F06e8-00031F-9v for hubmib@megatron.ietf.org; Fri, 20 Jan 2006 19:30:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15525 for <hubmib@ietf.org>; Fri, 20 Jan 2006 19:28:55 -0500 (EST)
Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F06mv-0005Bl-IF for hubmib@ietf.org; Fri, 20 Jan 2006 19:39:32 -0500
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id k0L0UAcU028631; Fri, 20 Jan 2006 16:30:10 -0800
Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id k0L0SWGx032644; Fri, 20 Jan 2006 16:28:32 -0800
Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id k0L0SQVh032621; Fri, 20 Jan 2006 16:28:26 -0800
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Fri, 20 Jan 2006 16:28:26 -0800
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: hubmib@ietf.org
Message-ID: <Pine.LNX.4.10.10601201623170.29711-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 44c13fcb5ac8234f1196c1913fbec387
X-Mailman-Approved-At: Sun, 22 Jan 2006 01:05:11 -0500
Cc: dromasca@avaya.com, MSquire@HatterasNetworks.com
Subject: [Hubmib] Response to comments on OAM doc
X-BeenThere: hubmib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Ethernet Interfaces an Hub MIB WG <hubmib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/hubmib>, <mailto:hubmib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:hubmib@ietf.org>
List-Help: <mailto:hubmib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/hubmib>, <mailto:hubmib-request@ietf.org?subject=subscribe>
Sender: hubmib-bounces@ietf.org
Errors-To: hubmib-bounces@ietf.org
HI,
It looks like much progress, and maybe with the comments
below incorroprated, the document will be ready for
a new WG last call and IESG submission.
------------------------------------------------------------
Response to OAM comments (email from Matt Squire on 10-jan-2006) -
dtp:20-jan-2006
-------------------------------------------------------------
Responses are prefixed by %%. For example:
%% This is an example
-------------------------------------------------------------
Hi David, Dan -
Below are my responses to the various comments. Many of the editorial
problems (spelling error, etc.) won't be listed here as they don't
really require discussion. I separated out what I consider the biggest
issues and talk about them first, then include responses to your
individual comments in the parts that follow.
- Matt
========================
Bigger issues:
a) "dot3" vs "efm". There were multiple comments related to whether
various names in the MIB should be "efm..." or "dot3...". Admittedly,
the reviewed version of the MIB had a mix of the two as it historically
went from "EFM OAM" to "EFM Common" to "OAM" to whatever. To be clear,
the OAM functionality of 802.3 is applicable to any Ethernet interface,
not just those defined in 802.3ah, so it applies to 1000BASE-X,
10/100BASE-T, etc. For that reason, I'd suggest we move everything to a
"dot3..." prefix rather than an "efm..." prefix, and to use "Ethernet
OAM" as a description rather than "EFM OAM" (which appears in a few
places).
%% Yes, I suggest the following:
%% DOT3-OAM-MIB for the module name, and
%% dot3OamMIB for the descriptor of the MODULE-IDENTITY definition
%% I believe that the prefix of the descriptors used throughout
%% the -03 document are "dot3Oam", so no change needed for them.
b) Improving description clauses. You commented that all description
clauses for tables need to contain XYZ, similarly for rows. I've
attempted to improve the description clauses based on your feedback.
c) Removing frame reception conditions in MIB descriptions. You had
multiple comments related to certain sections of the MIB (the OAM peer
objects) where the descriptions included detailed information on what
the values of various frame fields had to be in order to process the
frame. As an example, the MIB had:
An OAMPDU is indicated by a valid frame with (1) destination
MAC address equal to that of the reserved MAC address for Slow
Protocols (See 43B of [802.3ah]), (2) a lengthOrType field
equal to the reserved type for Slow Protocols, (3) and a Slow
Protocols subtype equal to that of the subtype reserved for
OAM.
You basically indicated that such details weren't needed in those
sections. I'm more than fine with removing it. It was added several
revisions ago when someone asked for more details about "when exactly
does this value get updated?" At that point I added descriptions like
the above to spell out as much as possible what has to be received for
this field to be updated. I'd personally love to remove it, as it's
just a bunch of extra words to me, but more than that I don't want to
add it back again later.
%% The question is whether the text is useful or distracting, or
%% even confusing.
%% I suggest that OAM PDU be defined in the explanatory text
%% (the text before the MIB module) with a reference to the
%% section in the appropriate IEEE document. And also duplicate
%% that definition an put it in the DESCRIPTION clause of
%% the MODULE-IDENTITY. Then, just say "OAM PDU" without
%% defining what is an OAM PDU.
d) You found a couple of problems with my RTF-RFC conversion process.
In what was Section 4.3, there was a mapping of SNMP to 802.3
attributes, and you rightfully pointed out there should be a section
header and introduction sentence or two. At some point when going from
the word RTF file to the text RFC, those were deleted. In the next rev,
there will be a Section 4.4 just for the SNMP/802.3 attribute mappings.
e) You pointed out some inconsistencies (and potential improvements) on
explaining when entries are created/deleted from various tables. My
suggestion going forward is to detail when entries are created in the
primary control table (dot3OamTable), indicating they are automatically
created for every Ethernet interface that supports OAM. And then say
that other tables have entries automatically created for every entry in
that primary table. The way things were written,
%% Here is a summary of my suggestion:
%% Table dot3OamTable - entries are in this table if OAM is
%% supported on this dot3 interface. These entries
%% are not added or deleted via SNMP operations, but
%% and present if the OAM function is supported.
%% (NOTE: on rereading the DESCRIPTION of object dot3OamConfigRevision,
%% I was confused. Shouldn't the description simply be
%% "The local value of the OAM configuration revision."
%% I don't understand the reference to local_statisfied
%% in 802.3ah 57.3.1.2. Also, can there be different
%% versions on different interfaces? And given that
%% the GMDO attribute is aOAMLocalRevision, why not
%% call this dot3OamLocalConfigRevision?)
%% Table dot3OamPeerTable - presently, an entry is in this table
%% for each entry in table dot3OamTable, and object
%% dot3OamPeerStatus indicates if the values of other
%% columns in the table are "valid". The point that I
%% was making was to either a) remove object dot3OamPeerStatus
%% and only put rows in the table that have "valid values",
%% or b) define values that should be returned when
%% the value of object dot3OamPeerStatus is 'inactive(2)'.
%% Table dot3OamLoopbackTable - an entry exists in this table
%% for each entry in table dot3OamTable where object
%% dot3OamFunctionsSupported has bit 'loopbackSupported(1)'
%% with value 1.
%% NOTE: what happens if a loopback is started, and then
%% the value of dot3OamOperStatus changes to some value
%% from 'operational(9)', and then cycles back to
%% 'operational(9)'. Is the loopback lost?
%% Table dot3OamStatsTable - an entry exists in this table
%% for each entry in table dot3OamTable. The counts
%% are not "reset" due to changes in dot3OamOperStatus.
%% Table dot3EventConfigTable - an entry exists in this table
%% for each entry in table dot3OamTable where object
%% dot3OamFunctionsSupported has bit ??
%% with value 1. The values are not affected by
%% changes in dot3OamOperStatus or dot3OamAdminStatus.
%% Table dot3OamEventLogTable - an entry exists in this table
%% for each event that has occurred up to the max
%% supported by the implementation. When the implementation
%% max is present, the addition of a new event result in
%% the deletion of one or more of the oldest events. The
%% value of the index object dot3OamEvetLogIndex increase
%% in value for each new entry, and when the max is reached
%% then the value restarts at zero.
- dot3OamPeerTable didn't always have an entry - it was written so that
you could add an entry once you learned the peer, then leave it in
there, but an entry wasn't required even if you were running OAM. I
suggest changing that so that an entry is always required, and the
various objects have mechanisms to indicate whether their values validly
reflect an actual OAM peer, or whether there is no peer. This reflects
several of your comments.
- dot3OamLoopbackTable didn't require an entry if the implementation
didn't support loopback (there was a condition "if loopback is
supported" in the description). Likewise, the dot3EventConfigTable
didn't always require an entry (it's an optional function as well).
Given the optional nature of certain functions (loopback, events, etc),
I wasn't sure whether the tables should always have an entry (with some
kind of 'not supported' indicator), or whether the tables should only
have entries if the function is supported, or if there was some other
approach. I'm open to suggestions.
f) In the dot3OamAdminState, I had a description that included:
Note that the value of this object is ignored when the
interface is not operating in full-duplex mode. OAM is not
supported on half-duplex links.
]] I'm not sure what "ignored" means here.
]] I don't believe that "ignored" is the right term.
]] Shouldn't whether the interface is in half or full-duplex
]] show up in the value of object dot3OamOperStatus?
]] I'm assuming that only interfaces that can operate
]] in full-duplex mode will be in this table. That
]] should of been said in the table DESCRIPTION clause.
This is a little trickier than I originally thought. OAM was intended
for full-duplex links, and some of the functions don't operate on
half-duplex links. So I was trying to say that OAM shouldn't run on
half-duplex links, so setting the admin state doesn't matter (hence the
ignored). I'm open to finding better ways of saying that. Looking back
at 802.3ah, I was unable to find the sections that indicate OAM doesn't
come up on half-duplex links. So I believe what happens is that OAM
would come up but some things might not work (anybody have a different
interpretation)? If that's the case (as I think now), then I will
probably have to rewrite that description to capture the proper
behavior. I'm not sure that reflecting the duplex of the interface in
the dot3OamStatus is either good or necessary. The OAM tables should
exist whether the interface is full/half/auto, so the potential to be in
full-duplex may be required, but you don't have to be in full-duplex
mode to have an entry in the OAM table (your duplex may be auto, TBD
later).
%% (I'm going to ignore the potential "degraded operation" while
%% in half-duplex.)
%% I just don't like the sentence "Note that the value is
%% ignored..."
%% Let's back up. I believe that an implementation will choose
%% which dot3 interfaces that it will support the OAM function.
%% A management app will be able to read the instances in table
%% dot3OamTable to determine this. Some dot3 interfaces will
%% support negotiation, and if the peer negotiates half-duplex,
%% then the OAM function will not operate. Likewise, if there
%% is no peer attached or the peer's interface is down the
%% OAM function will not operate. Likewise, if the peer doesn't
%% support the OAM function (it may not have code, or it may
%% be administratively disabled), the OAM function will not
%% operate.
%% Thus, I'm suggesting that you remove the sentence, and
%% add a new value for dot3OperStatus, such as
%% 'nonOperInHalfDuplex()', which would be returned
%% if dot3OamAdminState is 'enabled(2)', and the link is
%% in half duplex mode.
%% Also, dot3OperStatus needs a value when ifAdminStatus
%% is 'down(2)' or 'testing(3)', and when ifOperStatus
%% has a value other than 'up(1)'.
g) In the loobpack object, right now there is a separate status and
action attribute, so that you can set the action to start/stop loopback,
then go read the status. You suggested a combined status/action object.
First, I don't know what that means. Can you point me to an example in
some other document? Second, the current separation of action/status
was a result of discussions on either the list or at a meeting. All of
the examples that I was able to find or were given to me for similar
function had one attribute to initiate the action and another to return
the result.
%% Having one object or two is somewhat subjective. There are
%% plenty of examples of action/status objects. For example,
%% all RowStatus objects are action/status objects. Here are
%% the enum values from RFC 2579:
%% -- the following two values are states:
%% -- these values may be read or written
%% active(1),
%% notInService(2),
%%
%% -- the following value is a state:
%% -- this value may be read, but not written
%% notReady(3),
%%
%% -- the following three values are
%% -- actions: these values may be written,
%% -- but are never read
%% createAndGo(4),
%% createAndWait(5),
%% destroy(6)
h) You suggested combining dot3OamErrSymPeriodWindowHi and
dot3OamErrSymPeriodWindowLo into one CounterBasedGauge64. This was
discussed on the list previously and it was decided that was not
possible. The discussion centered on CounterBasedGauge64s as being
read-only counters. In this case, we need settable parameters as we're
trying to setup a threshold. So I was told CounterBasedGauge64s were
not applicable in that scenario, and that we needed to have two separate
attributes with rules to combine them.
%% I'm checking into options.
i) On the dot3EventLogTable, you had questions about the maximum size
and handling:
]] On this table, can it have an infinite number of entries?
]] Most likely not. In other tables, there is some indication
]] that says the max number (not always available), but
]] always something that says to either stop adding entries,
]] or delete the oldest, or some other algorithm to replace
]] the least important with a new one.
I suggest saying the size of the table is implementation dependent, and
that older entries are automatically replaced with newer entries when
the table gets full. Is that satisfactory?
%% See above.
j) In the event log table, you asked what were the running totals and
event totals. After reading 802.3ah, you indicated you know what they
mean, but a re-write of the description is in order. Here's my proposed
DESCRIPTION:
"Each Event Notification TLV contains a running total of the
number of times an event has occurred, as well as the number of
times an Event Notification for the event has been transmitted.
For non-threshold crossing events, the number of events
(dot3OamLogRunningTotal) and the number of resultant Event
Notifications (dot3OamLogEventTotal) should be identical.
For threshold crossing events, since multiple occurrences may
be required to cross the threshold, these values are likely
different. This value represents the total number of times one
or more of these occurrences have resulted in an Event
Notification (for example, 51 when 3253 symbol errors have
occurred since the last reset, which has resulted in 51 symbol
error threshold crossing events since the last reset).
"
k) You made suggestions on rearranging the hierarchy so that there is a
dot3OamNotifications off dot3OamMIB, and having the notifications
reference that. I'm fine with changing the tree that way so
Notifications are moved up in the tree.
l) In the reviewed versions, the compliance section has some
unconditionally optional groups, allowing for a mix and match set of
implementations. You suggested defining a minimum and maximum
compliance group. I don't have a suggestion here yet. I need to think
about it more, but would be interested in hearing opinions from anyone
else.
=================================
In the text below, I basically include the version of the draft with
your comments in it as was sent to the mailing list. From that text, I
removed certain sections that didn't have any comments, or had only what
I considered uncontroversial editorial comments. Where text was
removed, << Text deleted >> appears. Your comments are still prefixed
with ]], while I put "MBS:" in front of my response.
]] Reviewed 8-sept-2005, david t. perkins, dperkins@snmpinfo.com
]]
]] Global comments:
]] Comments are inserted in-line and each comment line
]] is preceded by "]]".
]]
]]1) A line of "-"s is used as a separator. This is problematic
]] and if a separator is desired, the it should be something
]] like -- **************************************************
]] (If the number of "-"s in a line is X, and mod(X,4)==1,
]] then a MIB compiler will report a parse error.)
MBS: No problem doing the change.
]]2) All the tables should have consistent info in the
]] DESCRIPTION clauses for the table and row definitions.
]] Minimally, the tables DESCRIPTION clause should describe
]] the table, and specify what determines the number of
]] entries in the table.
]] Minimally, the DESCRIPTION clause for rows should indicate
]] how rows are added and removed from tables. And if can
]] be done via direct SNMP operations, then the identification
]] of the RowStatus object.
]] Note that there is additional information that must be
]] contained in the DESCRIPTION clause as specified in
]] "Guidelines ... of MIB Documents"
]] <draft-ietf-ops-mib-review-guidelines-04.txt>
]] [MIBguidelines]
%% The I-D is now RFC 4181
MBS: I've attempted to update the objects as appropriate. They'll
need to be reviewed to ensure they meet the goals.
]]3) For enumerated values, each value be described in the
]] DESCRIPTION text of the object or TC definition.
MBS: I found a couple instances where not every enumerated value was
spelled out, and tried to correct that (you have specific comments to
these at the various instances of the omission).
]]5) The term "byte" should be replaced by term "octet".
MBS: Changed.
]]6) The abbreviations "i.e.", and "e.g." are confused.
]] I suggest that you always write out "that is",
]] and "for example".
MBS: I replaced the few occurences of "e.g." with "for example".
Personally, I don't believe that it improves (or hurts) anything, but
I'm more than willing to do it. The abbreviation "i.e." wasn't used
in the document (that I could find).
]]7) A few typos were found by idnits script found at
]] http://ietf.levkowetz.com/tools/idnits/
MBS: I'll be sure to run the script on next revision before
submission.
Ethernet Interfaces and Hub MIB WG
Internet Draft Matt Squire
Document: draft-ietf-hubmib-efm-mib-03.txt Hatteras Networks
Expires: September 2005 March, 2005
Ethernet in the First Mile (EFM) OAM MIB
<< Text deleted >>
%% I hope that you are changing this to the following:
%% Definitions of Managed Objects for OAM Functions for
%% Ethernet-Like Interfaces
3. Overview
Ethernet networks have evolved over the past 30 years from simple
LANs to a variety of other applications, including wide area
networks. To address some of these emerging markets, the IEEE
802.3ah task force defined additional clauses for the IEEE 802.3
standard [802.3-2002] to better address Ethernet deployments in the
public access network.
]] To make it clear, I'd change the above to the following:
]] To address some of these emerging markets, the IEEE
]] 802.3ah task force defined additional clauses in [802.3ah]
]] for the IEEE 802.3 standard [802.3-2002] to better address
]] Ethernet deployments in the public access network.
MBS: Changed made.
]] Is 802.3ah work strictly for "public access networks"?
]] If not, then the phrase should be dropped or replaced.
MBS: Access networks were the motivation for the task force, but the
results can be applied for any application. So the phrase does
address why the work was initiated and completed, but does not fully
address applicability. Instead of the suggestion, I added a sentence;
"Although Ethernet access deployments were the primary motivation for
the task force work, the results of the task force are not limited to
that application. "
<< Text deleted >>
4.1 Relation to other SNMP MIB Modules
This objects defined in this document do not overlap with MIB-2
[RFC1213], the interfaces MIB [RFC2863], or the Ethernet like
interfaces MIB [RFC3635]. The objects defined here are defined for
Ethernet like interfaces only and use the same ifIndex as the
associated Ethernet interface. Ethernet OAM can be implemented on
any Ethernet like interface managed via these MIBs.
]] The "This" should be "The".
]] MIB-2 is obsolete, and I'm not sure what this section is
]] trying to say. I'm not sure that this functionality
]] can be applied on any "Ethernet-like" interfaces,
]] and not just on the interface types as specified
]] in [802.3ah].
MBS: The OAM functionality controlled by this MIB can be applied to
any Ethernet interface (for example, 10/100BASE-T). This was an
explicit goal of the OAM sub taskforce. This paragraph is attempting
to say that this MIB does not overlap with existing MIBs used to
manage Ethernet interfaces (several examples given via references).
However, it is noted that the indexing scheme is the same. I can
certainly try to re-write it again to make that point better. One
possible wording would be:
"The objects defined in this document manage OAM functionality
introduced in [802.3ah] These objects do not overlap with
MIB-2 [RFC1213], the interfaces MIB [RFC2863], the Ethernet like
interfaces MIB [RFC3635], or any other MIB currently used to
manage various aspects of an Ethernet interface. The objects
defined here are defined for Ethernet like interfaces only and
use the same ifIndex as the associated Ethernet interface.
Ethernet OAM can be implemented on any Ethernet like interface."
%% Please drop the MIB-2 [RFC1213] reference, since it is obsoleted
%% or updated by other documents.
4.2 Relation to other EFM MIB Modules
The Ethernet OAM functionality and MIB Module is independent of the
other functionality and MIB Modules derived from [802.3ah] for copper
[802.3ah-copper] and EPON [802.3ah-epon].
Ethernet OAM may be implemented on point-to-multipoint EFM EPON
interfaces. However, because higher layer protocols that run over
Ethernet interfaces are not designed for the partial connectivity
provided by a point-to-multipoint interface, EPON provides a point
to-point emulation layer (see [802.3ah] and [802.3ah-epon]) whereby
the single EPON interface of 1-to-N connectivity is represented by N
point-to-point interfaces. Ethernet OAM, like any other protocol at
the Ethernet layer or above (for example, bridging), utilizes the
point-to-point emulation layer of EPON in that the EPON interface is
viewed as N point-to-point Ethernet interfaces. Thus OAM, and other
protocols, do not need to be altered for the EPON environment.
Ethernet OAM may be implemented on the 2BASE-TL and 10PASS-TS
Ethernet-over-copper interfaces defined in EFM [802.3ah]. 2BASE-TL
and 10PASS-TS can be aggregated interfaces, meaning that they can use
the ifStackTable of the Interfaces Group MIB [RFC2863] to manage a
set of N (1 <= N <= 32) physical layers into a single Ethernet
interface.
The other Ethernet interfaces introduced in EFM [802.3ah] are simply
new optical physical layers that are managed by minimal extensions to
the MAU MIB [RFC3636] defining new types of Ethernet interfaces.
%% I don't believe that "EFM interface types" need any special
%% mention. The key point is that the OAM function can function
%% on any etherLike interface and (if I understand you correctly)
%% any aggregated interface that uses an aggregation of etherLike
%% interfaces.
4.3 IANA Considerations
The EFM OAM MIB requires the allocation of a single object identifier
for its MODULE-IDENTITY under the MIB-2 tree. IANA has not yet
allocated this object identifier.
]] This needs to be updated to follow the format as
]] specified in [MIBguidelines]
MORE
%% See, for example section 5 in RFC 4188
]] The list that follows seems out of place. At the minimum
]] there needs to be a section header and intro.
]]
]] NOTE: I didn't check the list below for errors, such
]] as omissions and spellings.
MBS: The lack of header/intro is apparently an artifact of RTF->I-D
format conversion. I'll fix it in the next revision. The headers and
introduction exist in my RTF file.
[802.3ah] Clause 30, and managed objects defined in this document.
IEEE 802.3 Managed Object Corresponding SNMP object
]] In the below, it would be useful to also show the object class
]] (the oXXX) containing each attribute. For example, the MAU MIB
]] document (draft-ietf-hubmib-rfc3636bis-01.txt) does this.
MBS: Easy enough to do (there's just oOAM).
.aOAMID IF-MIB ifIndex
5. MIB Structure
The common EFM MIB objects of this memo focus on the OAM capabilities
introduced in IEEE 802.3ah. The MIB objects are partitioned into six
]] Probably want [803.3ah] instead of just 802.3ah
MBS: Done
different MIB groups.
The dot3OamTable group manages the primary OAM objects of the
Ethernet interface. This group controls the state and status of OAM
as well as the mode in which it operates.
The dot3OamPeerTable maintains the current information on the status
and configuration of the peer OAM entity on the Ethernet interface.
Managed information includes the capabilities and function available
]] I think "capabilities" and "function" are the same, so
]] I would drop "and function".
MBS: I'm not sure I agree with that. Capabilities generally refers to
what the other guy can do, while functions refers to what it does. Some
capabilities may be disabled or inoperable for many reasons. So I'm
trying to say that the MIB covers both potential and actual
functionality.
on the peer OAM entity.
The dot3OamLoopbackTable manages the loopback function introduced in
EFM [802.3ah]. This table controls enabling and disabling loopback,
]] Is there a difference between "EFM [802.3af]" and "[802.3af]"?
]] If so, this needs to be reflected throughout the the
]] document. If not, then the "EFM" should be removed.
MBS: No difference,so I removed EFM. The benefit of having it in
there is that many people know the project as EFM, even though this
function is not restricted to the physical layers of that project.
as well as indicating the loopback status of Ethernet OAM on this
interface.
]] Above and through the document, the terms "Ethernet OAM",
]] and "EFM OAM" are used. Are these the same, or different?
]] If different, then this needs to be explained. If the
]] same, then one should be chosen and used consistently.
MBS: There's no intended difference. As the OAM functionality applies
to any Ethernet interface, I will go with Ethernet OAM rather than EFM
OAM.
<< Text deleted >>
6. MIB Definition
EFM-COMMON-MIB DEFINITIONS ::= BEGIN
]] This module name doesn't follow the naming conventions
]] in the [MIBguidelines] document. However, I can't determine
]] if it should be DOT3-OAM-MIB, or "EFM-OAM-MIB".
MBS: It should be DOT3-OAM-MIB to me, so that's what I'll change it to.
<<text deleted>>
efmOamMIB MODULE-IDENTITY
]] Not sure if should be efmOamMIB or dot3OamMIB
MBS: Changed to dot3OamMIB
<<text deleted>>
DESCRIPTION
"The MIB module for managing the new Ethernet OAM features
introduced by the Ethernet in the First Mile task force (IEEE
802.3ah). The functionality presented here is based on IEEE
802.3ah [802.3ah], released in October, 2004.
In particular, this MIB focused on the changes to Clause 30 of
the draft that are not specific to any physical layer. These
changes are primarily reflected in the new OAM features
developed under this project, that can be applied to any
Ethernet like interface. The OAM features are described in
Clause 57 of [802.3ah].
]] First, is it clause 30 or 57.
]] Also, the above reads strangely. People that don't understand
]] exactly how IEEE documents are updated (which is very different
]] than how IETF documents are updated).
MBS: Attempted re-wording below. Hopefully this will make more sense
to you. The functionality is described in one clause, but the
management attributes of that functionality are described in another.
"In particular, this MIB focuses on the new OAM functions
introduced in Clause 57 of [802.3ah]. The OAM functionality of
Clasue 57 is controlled by new management attributes introduced
in Clause 30 of [802.3ah]. The OAM functions are not specific
to any particular Ethernet physical layer, and can be
generically applied to any Ethernet interface of [802.3-2002].
"
%% looks good
<< Text deleted >>
--
-- Ethernet OAM Control group
--
dot3OamTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3OamEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Primary controls and status for the OAM capabilities of an
Ethernet like interface. There will be one row in this table
for each Ethernet like interface in the system that supports
the Ethernet OAM functions defined in [802.3ah]."
::= { dot3OamMIB 1 }
]] I'm still unclear as to exactly which interfaces will be
]] in this table. For example, if a 10baseT interface card
]] is plugged into the device, will a new row show up?
]] Or is it only for the Cu and EPON interfaces?
]] And does some other configuration (outside of SNMP)
]] configuration have to be done?
]] I believe the answer is not, but want to determine
]] if aggregated interfaces can exist in the table?
MBS: Any Ethernet interface that can appear in the Ethernet like MIB
table can appear here if OAM functionality is supported. So the
answer to your questions are
- yes, if the interfaces support Ethernet OAM (which is optional)
- no, it is not only for the Cu/EPON interfaces
- no, no other configuration is required
%% Just to be sure, if an aggregation interface is created using
%% members that are etherLike, can the aggregation have OAM
%% applied, or is it only for the base links. For example,
%% I can create an aggregation interface from, say 4 1Gig Ethernet
%% interfaces. In this case is the aggregation interface
%% supported by OAM?
dot3OamEntry OBJECT-TYPE
SYNTAX Dot3OamEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table, containing information on the Ethernet
OAM function for a single Ethernet like interface."
INDEX { ifIndex }
::= { dot3OamTable 1 }
]] The SMI requires in the DESCRIPTION clause for a row,
]] a description of index objects that not defined in the
]] table.
MBS: Added a description that says when entries created/deleted and the
row status.
%% Don't need a RowStatus column for this table. Just need to say
%% that entries are not created or deleted via SNMP operations.
Dot3OamEntry ::=
SEQUENCE {
dot3OamAdminState INTEGER,
dot3OamOperStatus INTEGER,
dot3OamMode INTEGER,
dot3OamMaxOamPduSize Integer32,
dot3OamConfigRevision Unsigned32,
dot3OamFunctionsSupported BITS
}
dot3OamAdminState OBJECT-TYPE
SYNTAX INTEGER {
disabled(1),
enabled(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is used to provision the default administrative
OAM mode for this interface. This object represents the
desired state of OAM for this interface.
The dot3OamAdminState always starts in the disabled(1) state
until an explicity management action or configuration
]] ^^^^^^spelling error
MBS: Fixed.
information retained by the system causes a transition to the
enabled(2) state.
Note that the value of this object is ignored when the
interface is not operating in full-duplex mode. OAM is not
supported on half-duplex links. "
REFERENCE "[802.3ah], 30.3.6.1.2"
::= { dot3OamEntry 1 }
]] I'm not sure what "ignored" means here.
]] I don't believe that "ignored" is the right term.
]] Shouldn't whether the interface is in half or full-duplex
]] show up in the value of object dot3OamOperStatus?
]] I'm assuming that only interfaces that can operate
]] in full-duplex mode will be in this table. That
]] should of been said in the table DESCRIPTION clause.
MBS: This is a little tricky. Certain functions in Ethernet OAM
assume full-duplex links. So I tried to say that you should ignore
the provisioned enable/disable admin state if the link comes up
half-duplex, and just leave OAM disabled. Certainly a link should
have the capacity to be full-duplex to appear in this table. However,
if the interface hasn't negotiated duplex yet, we should still allow
it in the table so that OAM can be configured in case the link comes
up full-duplex.
MBS: This behavior is certainly up for
interpretation. We could allow OAm to operate on half-duplex links
though not every function will be available. Open to suggestions.
%% see above
dot3OamOperStatus OBJECT-TYPE
SYNTAX INTEGER {
disabled(1),
linkfault(2),
passiveWait(3),
activeSendLocal(4),
sendLocalAndRemote(5),
sendLocalAndRemoteOk(6),
oamPeeringLocallyRejected(7),
oamPeeringRemotelyRejected(8),
operational(9)
}
]] What values indicate that ifAdmin status is set down
]] or testing?
]] What are the values when ifOperStatus is not up?
]] It seems like some of these could occur concurrently.
]] Is this possible?
MBS: if the physical layer is not up, OAM will be in linkfault state
(regardless of whether its down, testing, or anything else). The
linkFault state is the starting state for any enabled OAM
implementation. There are OAM state machines in [802.3ah] that define
the 9 states above, and one and only one is possible at any time.
%% See above. Please state this in the DESCRIPTION. However
%% oper and admin work in the IETF management model is DIFFERENT
%% from the ITU module. Don't know the IEEE model.
%% In IETF oper "follows" admin. That is, when admin is down,
%% then oper is down. In ITU, oper is independent from admin.
%% That is, when admin is down (ITU calls this locked), then
%% oper is suppose to tell you if the interface can still
%% work, and would normally be "up".
<< Text deleted >>
dot3OamMaxOamPduSize OBJECT-TYPE
SYNTAX Integer32 (64..1522)
]] This should be Unsigned32.
]] Also, is 1522 really the max?
MBS: I'll change to Unsigned32 though its not clear to me why thats
better. The maximum value, as defined in [802.3ah] is equal the
maximum untagged frame size (which is undergoing change in 802.3 as we
speak). I'd like to put a variable in here that ties it to the
maxUntaggedFrameSize, but I don't know what that variable would be.
Numerically, it should currently be 1518, not 1522.
UNITS "bytes"
%% octets please
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The largest OAMPDU that the OAM entity supports. OAM
entities exchange maximum OAMPDU sizes and negotiate to use
the smaller of the two maximum OAMPDU sizes between the peers.
This value is determined by the local implementation.
"
REFERENCE "[802.3ah], 30.3.6.1.8"
::= { dot3OamEntry 4 }
<< Text deleted >>
------------------------------------------------------------------
--
-- Ethernet OAM Peer group
--
dot3OamPeerTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3OamPeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about the OAM peer for a particular Ethernet like
interface. OAM entities communicate with a single OAM peer
entity on full-duplex Ethernet links on which OAM is enabled
and operating properly.
In certain states, the OAM peer information is not available.
Whether peer information is available is communicated via the
dot3OamPeerStatus object. When this object is inactive, all
other information in the row is to be considered invalid. "
::= { dot3OamMIB 2 }
]] Fix this table DESCRIPTION as per global comments
]] The issue of communicating that when the value of dot3OamPeerStatus
]] is 'inactive(2)' that the values of the other columns is
]] unknown, is difficult. Yes, it is said in the DESCRIPTION
]] clause for the row, but I suggest that you also put
]] that in the DESCRIPTION clause for each column. Also,
]] if possible, define a value for each column that is
]] returned when dot3OamPeerStatus is 'inactive(2)',
]] which CAN NOT be a valid value with dot3OamPeerStatus
]] has value 'active(1)'.
MBS: I've attempted to incorporate this comment in the next revision,
and the invalid statement is repeated for every column. Its not clear
how to devine unique invalid values for every column - for example a
bits field or an unsigned32 where all 2^32 values are allowed. So I
wasn't able to implement that part of the comment for every column.
dot3OamPeerEntry OBJECT-TYPE
SYNTAX Dot3OamPeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table, containing information on the peer OAM
entity for a single Ethernet like interface.
Note that there is at most one OAM peer for each Ethernet like
interface. There is exactly one row in this table for each
Ethernet like interface supporting OAM. "
INDEX { ifIndex }
::= { dot3OamPeerTable 1 }
]] Fix. Note, I believe it would be clearer to say
]] (in the DESCRIPTION for the table) that a row
]] exists in this table for each row in the OAM control
]] table.
MBS: I'm not sure what you mean by the "OAM control table", but the
intent is that there is at most one row for every entry in the
dot3OamTable. There may be zero rows in this table for an entry in
the dot3OamTable if the peer information has not been discovered
(yet). I guess we could say there's always a row but that its
information is inactive(2) - is that your point? That probably is
simpler.
%% see above.
%% You either have a one-to-one relationship with rows in the
%% control table (dot3OamTable) (and you have object dot3OamPeerStatus),
%% or you have a subset of the rows (and you don't need object
%% dot3OamPeerStatus).
Dot3OamPeerEntry ::=
SEQUENCE {
dot3OamPeerStatus INTEGER,
dot3OamPeerMacAddress MacAddress,
dot3OamPeerVendorOui Dot3Oui,
dot3OamPeerVendorInfo Unsigned32,
dot3OamPeerMode INTEGER,
dot3OamPeerMaxOamPduSize Integer32,
dot3OamPeerConfigRevision Unsigned32,
dot3OamPeerFunctionsSupported BITS
}
dot3OamPeerStatus OBJECT-TYPE
SYNTAX INTEGER {
active(1),
inactive(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates whether the information in this row
should be considered valid. When active(1), the information
is valid and represents the current peer of the OAM entity.
When inactive(2), the information in this row is invalid.
A value of inactive(2) is returned if the dot3OamOperStatus is
disabled, passiveWait, or activeSendLocal. For all other
values of dot3OamOperStatus, a value of active(1) is returned.
"
::= { dot3OamPeerEntry 1 }
]] The above doesn't seem possible. Please check.
]] It seems that only when dot3OamOperStatus has the
]] value of 'operational(9)' can this have value 'active(1)'
MBS: The intent is that you know about the peer entity before OAM
becomes fully operational(9). As soon as you receive one frame from
the peer you know their basic info (there is a multi-frame exchange
required for initialization). So I believe the statement is correct
as is.
%% Please add the above in the DESCRIPTION
dot3OamPeerMacAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The MAC address of the peer OAM entity. The MAC address is
derived from the most recently received OAMPDU. This value is
initialized to all zeros (0x000000000000). This value is
invalid if the dot3OamPeerStatus is inactive.
]] This seems pretty convoluted. Why not say "The MAC address
]] of the peer OAM entity. The MAC address is
]] derived from the most recently received valid OAMPDU.
]] The value is all zeros (0x000000000000) when the peer's
]] MAC address unknown, such as when the value of
]] dot3OamPeerStatus is 'inactive(2)'."
]]
]] By the way, it seems like a value could be obtained
]] even when dot3OamPeerStatus is 'inactive(2)'.
]] If so, is it useful?
MBS; I didn't see any use, hence the current indications that its
garbage if 'inactive'. Related to your general comment of
simplification, I'll change the description to indicate zeros are
returned whenever the dot3OamPeerStatus is inactive(2).
An OAMPDU is indicated by a valid frame with (1) destination
MAC address equal to that of the reserved MAC address for Slow
Protocols (See 43B of [802.3ah]), (2) a lengthOrType field
equal to the reserved type for Slow Protocols, (3) and a Slow
Protocols subtype equal to that of the subtype reserved for
OAM. "
]] Not sure this is needed in this definition.
MBS; I don't mind removing it - in fact I prefer to. It was added
because I was asked to specfically define what causes this value to
change. The event that causes an update to this value is the
reception of an OAMPDU, which is defined as above. I'm thrilled to be
allowed to kill it.
%% see above
REFERENCE "[802.3ah], 30.3.6.1.5."
::= { dot3OamPeerEntry 2 }
dot3OamPeerVendorOui OBJECT-TYPE
SYNTAX Dot3Oui
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The OUI of the OAM peer as reflected in the latest
Information OAMPDU received with a Local Information TLV. The
OUI can be used to identify the vendor of the remote OAM
entity. This value is initialized to all zeros (0x000000).
This value is considered invalid if the dot3OamPeerStatus is
inactive.
]] Can this be written to be simpler (see above)
MBS; Simplification will be attempted in next revision.
REFERENCE "[802.3ah], 30.3.6.1.16."
::= { dot3OamPeerEntry 3 }
dot3OamPeerVendorInfo OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Vendor Info of the OAM peer as reflected in the latest
Information OAMPDU received with a Local Information TLV. The
vendor information field is within the Local Information TLV,
and can be used to determine additional information about the
unspecified within the 32-bit field. This value is intialized
]] spelling error^^^^^^^^^
MBS: fixed.
to all zeros (0x00000000). This value is invalid if the
dot3OamPeerStatus is inactive.
]] Can this be written to be simpler (see above)
]] Also, the 802.3af spec is confusing to me. From
]] it, the value seems like it should have
]] SYNTAX clause value of OCTET STRING(SIZE(4)).
]] But maybe an "Unsigned32" value is OK. If so,
]] the 0x00000000 is very strange. It should just be 0.
MBS: I left this as Unsigned32 as its just a 32-bit field,
non-formatted field. But I switched to 0 instead of 0x00000000.
REFERENCE "[802.3ah], 30.3.6.1.17."
::= { dot3OamPeerEntry 4 }
<< Text deleted >>
------------------------------------------------------------------
--
-- Ethernet OAM Loopback group
--
dot3OamLoopbackTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3OamLoopbackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains methods to control the loopback state of
the local link as well as indicating the status of the
loopback function.
Loopback can be used to place the remote OAM entity in a state
where every received frame (except OAMPDUs) are echoed back
over the same interface on which they were received. In this
state, at the remote entity, 'normal' traffic is disabled as
only the looped back frames are transmitted on the interface.
Loopback is thus an intrusive operation that prohibits normal
data flow and should be used accordingly. "
::= { dot3OamMIB 3 }
]] See global comment about tables, and comment on table
]] dot3OamPeerTable.
MBS: done
]] This table is used to put the remote end in loopback
]] and report the loopback status of the local and remote
]] ports
]] I'm confused as to whether both local and remote ports
]] can be put in loopback. And if not, then what happens
]] if the peer has put the local port in loopback and
]] an attempt is made to put the peer's port (the remote
]] port) in loopback?
MBS: Simultaneous loopback on both ends is not possible - the protocol
detects such an action and an election algorithm is used to determine
which port enters loopback state and which does not.
dot3OamLoopbackEntry OBJECT-TYPE
SYNTAX Dot3OamLoopbackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table, containing information on the loopback
status for a single Ethernet like interface. There is an
entry in this table for every Ethernet like interface on which
supports OAM and loopback function within OAM (as indicated in
dot3OamFunctionsSupported). "
]] See previous comments on rows
MBS: Changed to indicated automatic creation and conditions.
INDEX { ifIndex }
::= { dot3OamLoopbackTable 1 }
<<text deleted>>
dot3OamLoopbackCommand OBJECT-TYPE
SYNTAX INTEGER {
noLoopback (1),
startRemoteLoopback (2),
stopRemoteLoopback (3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This attribute initiates or terminates remote loopback with
an OAM peer. Writing startRemoteLoopback(2) to this attribute
cause the local OAM client to send a loopback OAMPDU to the
OAM peer with the loopback enable flags set. Writing
stopRemoteLoopback(3) to this attribute will cause the local
OAM client to send a loopback OAMPDU to the OAM peer with the
loopback enable flags cleared. Writing noLoopback to this
attribute has no effect.
Writes to this attribute are ignored unless the OAM status of
this interface is 'operational' (dot3OamOperStatus).
The attribute always returns noLoopback on a read. To
determine the loopback status, use the attribute
dot3OamLoopbackStatus. "
REFERENCE "[802.3ah], 57.2.11"
::= { dot3OamLoopbackEntry 1 }
]] This object and the next need to be combined into a
]] action/status object.
]] The combined object support all the enum values
]] for dot3OamLoopbackStatus (which would be read-only)
]] and startRemoteLoopback and stopRemoteLoopback
]] from this object. Writes of startRemoteLoopback
]] when remote is already loopbacked (or dot3OamOperStatus
]] is not operational) cause no operation.
]] Likewise, writes of stopRemoteLoopback when remote
]] is not loopbacked (or dot3OamOperStatus
]] is not operational) cause no operation.
]] Note: just don't know what happens when
]] current value is localLoopback.
MBS: I can change it, but I'd like to be pointed to an example. All
of the examples I've come across had two objects, one for the actions,
one for the status, which is where this model comes from. During
discussion with the group, two objects were suggested as the desired
approach.
<< Text deleted >>
------------------------------------------------------------------
--
-- Ethernet OAM Statistics group
--
dot3OamStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3OamStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Statistics for the OAM function on a particular Ethernet like
interface."
::= { dot3OamMIB 4 }
]] See previous comments on tables.
MBS: Done
]] Add a note in the commentary section as to why the counters
]] in this table are Counter32 instead of Counter64!
MBS: Done. The size of the counters was selected to match the size of
the counters as defined in 802.3.
<< Text deleted >>
dot3OamUnsupportedCodesTx OBJECT-TYPE
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of OAMPDUs transmitted on this
interface with an unsupported op-code.
]] This is very strange.
]] Why would you send an "unsupported code"?
]] How would you know that you sent an "unsupported code"?
MBS: Granted it seems a little strange. The variable is supported in
the 802.3ah standard, so I decided to expose it via the MIB. Since
Ethernet OAM could be supported in the HW or in the SW, the thought
was someone might try to do things where the underlying layer doesn't
support that thing (for example, loopback), and you might want to know
about it.
%% Does the other end tell you that you have sent an unsupported
%% op-code?
<< Text deleted >>
dot3OamFramesLostDueToOam OBJECT-TYPE
]] Strange descriptor. How about "dot3OamDroppedTxFrames"
MBS: I'm trying to match the names in 802.3ah as closely as possible
to make the implmeentaiton easier. In 802.3, its called
FramesLostDueToOam. The reason its not "OamDroppedTxFrames" is
because that might sound like OAM frames are dropped, when really any
frame might be dropped because OAM took precedence.
%% I'm not sure I could figure that out the above. Why not put it
%% in the DESCRIPTION
SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of frames that were dropped by the OAM
multiplexer. Since the OAM mulitplexer has multiple inputs
and a single output, there may be cases where frames are
dropped due to transmit resource contention. This counter is
incremented whenever a frame is dropped by the OAM layer.
When this counter is incremented, no other counters in this
MIB are incremented.
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. "
REFERENCE "[802.3ah], 30.3.6.1.46."
::= { dot3OamStatsEntry 17 }
------------------------------------------------------------------
--
-- Ethernet OAM Event Configuration group
--
<< Text deleted >>
dot3OamErrSymPeriodWindowHi OBJECT-TYPE
]] This needs to be combined with the next object
]] and given syntax CounterBasedGauge64
MBS: This was discussed on the list. The discussion said that
CounterBasedGauge64 is read-only and since this is a writable value,
it wouldn't apply.
%% Sorry, you are correct
<< Text deleted >>
dot3OamErrFrameWindow OBJECT-TYPE
SYNTAX Unsigned32
UNITS "tenths of a second"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The amount of time (in 100ms increments) over which the
]] why not just say "in tenth of a second intervals" instead
]] of "in 100ms intervals"
MBS: 100ms seems easier to say then "tenths of a second"
threshold is defined. The default value is 10 (1 second).
If dot3OamErrFrameThreshold frame errors occur within a window
of dot3OamErrFrameWindow seconds (measured in tenths of
seconds), an Event Notification OAMPDU should be generated with
an Errored Frame Event TLV indicating the threshold has been
crossed in this window. "
REFERENCE "[802.3ah], 30.3.6.1.36"
::= { dot3OamEventConfigEntry 9 }
dot3OamErrFrameThreshold OBJECT-TYPE
SYNTAX Unsigned32
]] What happens when the value is zero?
MBS: This would result in an event notification being sent at the end
of every measuring period. So if the window were 30sec, you'd get an
OAMPDU every 30s saying how many errored frame there were. Some may
consider this useless,but others thought it a way to get regular
periodic updtes on these error counters (e.g. tell me what the values
are every 30s).
%% so why not include that in the DESCRIPTION
<< Text deleted >>
------------------------------------------------------------------
--
-- Ethernet OAM Event Status group
--
dot3OamEventLogTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3OamEventLogEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
]] See comments on tables
]] On this table, can it have an infinite number of entries?
]] Most likely not. In other tables, there is some indication
]] that says the max number (not always available), but
]] always something that says to either stop adding entries,
]] or delete the oldest, or some other algorithm to replace
]] the least important with a new one.
MBS: Added words to say that size is implemetnation dependent, and
that older entries should be automtically deleted to make room for
newer entries.
%% see above
"This table records a history of the events that have occurred
at the Ethernet OAM level. These events can include locally
detected events, which may result in locally generated
OAMPDUs, and remotely detected events, which are detected by
the OAM peer entity and signaled to the local entity via
Ethernet OAM. Ethernet OAM events can be signaled by Event
Notification OAMPDUs or by the flags field in any OAMPDU. "
]] Need to indicate that there are threshold crossing events
]] and nonthreshold events. For each, indicate the columns that
]] have meaningful values. The descriptions about the MAX values
]] didn't make sense until I read the descriptions of the
]] notifications and saw what was going on.
MBS: Added words to say which columsn only apply to threshold crossing
events.
::= { dot3OamMIB 6 }
dot3OamEventLogEntry OBJECT-TYPE
SYNTAX Dot3OamEventLogEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in the dot3OamEventLogTable."
]] See previous comments on rows.
MBS: Done.
]] Can selected entries in this table be deleted by
]] management operations?
MBS: The thought was no,that the table reflects what happened (to the
extent that it can).
INDEX { ifIndex, dot3OamEventLogIndex }
::= { dot3OamEventLogTable 1 }
<< Text deleted >>
dot3OamEventLogType OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of event that generated this entry in the event log.
When the OUI is the IEEE 802.3 OUI of 0x0180C2, the following
event types are defined:
erroredSymbolEvent(1),
erroredFramePeriodEvent (2),
erroredFrameEvent(3),
erroredFrameSecondsEvent(4),
linkFault(256),
dyingGaspEvent(257),
criticalLinkEvent(258)
The first four are considered threshold crossing events as
they are generated when a metric exceeds a given value within
a specified window. The other three are not threshold
crossing events.
When the OUI is not 0x0180C2, then some other organization has
defined the event space. If event subtyping is known to the
implementation, it may be reflected here. Otherwise, this
value should return all Fs (0xFFFFFFFF).
"
]] If this is an Unsigned32, then say this in numeric
]] terms and not in terminology used for octet strings.
MBS: added decimal value in addition to all Fs.
REFERENCE "[802.3ah], 30.3.6.1.10 and 57.5.3."
::= { dot3OamEventLogEntry 4 }
<< Text deleted >>
]] I'm not sure that I understand the objects
]] dot3OamEventLogRunningTotal and
]] dot3OamEventLogEventTotal. It
]] seems like dot3OamEventLogRunningTotal is the
]] value of a counter that is being thresholded,
]] and dot3OamEventLogEventTotal is the count of
]] the event crossings.
]] These counts seem possibly expensive to do.
]] Ok - after reading 802.3af, I see what is going on.
]] The descriptions below are really difficult to
]] understand. They need a rewrite.
MBS: Rewrite will be attempted.
<< Text deleted >>
------------------------------------------------------------------
--
-- Ethernet OAM Notifications
--
dot3OamNotifs OBJECT IDENTIFIER ::= { dot3OamMIB 7 }
dot3OamNotifsPrefix OBJECT IDENTIFIER ::= {dot3OamNotifs 0}
]] remove these, and update OID values for notifications
MBS: I will delete these and replace the dot3OamNotifsPrefix in the
object below with dot3OamNotifications that you added earlier in the
MIB.
<< Text deleted >>
------------------------------------------------------------------
--
-- Ethernet OAM Compliance group
--
dot3OamGroups OBJECT IDENTIFIER ::= { dot3OamConformance 1 }
dot3OamCompliances OBJECT IDENTIFIER ::= { dot3OamConformance 2 }
-- Compliance statements
dot3OamCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for managed entities
supporting OAM on Ethernet like interfaces.
"
MODULE -- this module
MANDATORY-GROUPS { dot3OamControlGroup,
dot3OamPeerGroup,
dot3OamStatsBaseGroup
}
GROUP dot3OamLoopbackGroup
DESCRIPTION
"This group is mandatory for all IEEE 802.3 OAM
implementations that support loopback functionality. "
GROUP dot3OamErrSymbolPeriodEventGroup
DESCRIPTION
"This group is mandatory for all IEEE 802.3 OAM
implementations that support event functionality. "
GROUP dot3OamErrFramePeriodEventGroup
DESCRIPTION
"This group is mandatory for all IEEE 802.3 OAM
implementations that support event functionality. "
GROUP dot3OamErrFrameEventGroup
DESCRIPTION
"This group is mandatory for all IEEE 802.3 OAM
implementations that support event functionality. "
GROUP dot3OamErrFrameSecsSummaryEventGroup
DESCRIPTION
"This group is mandatory for all IEEE 802.3 OAM
implementations that support event functionality. "
GROUP dot3OamFlagEventGroup
DESCRIPTION
"This group is optional for all IEEE 802.3 OAM
implementations. The ability to send critical events or
dying gasp events is not required in any system."
GROUP dot3OamEventLogGroup
DESCRIPTION
"This group is optional for all IEEE 802.3 OAM
implementations. "
]] There will not be any local events in the log table
]] unless some of the event groups are implemented.
MBS: Correct. Is that a question or are you suggesting some action?
%% The descriptions specify dependencies.
GROUP dot3OamNotificationGroup
DESCRIPTION
"This group is optional for all IEEE 802.3 OAM
implementations. "
]] This group requires implementation of the log table,
]] since the objects in the notifications are objects
]] in the log table!
MBS: I'm not sure what to do here, will have to think about it.
::= { dot3OamCompliances 1}
]] The way this module compliance is written, there are
]] a couple of unconditionally optional items (like the
]] notifications and logging). Also, there can be mix and
]] match of optional items. This is bad for IETF standards
]] track progression. You might consider having two
]] module compliance specifications - a minimal and
]] maximal. Others, like Bert, and provide better
]] advice as to the best practices in IETF standards
]] track MIB modules.
<<text deleted>>
dot3OamStatsBaseGroup OBJECT-GROUP
OBJECTS { dot3OamInformationTx,
dot3OamInformationRx,
dot3OamUniqueEventNotificationTx,
dot3OamUniqueEventNotificationRx,
dot3OamDuplicateEventNotificationTx,
dot3OamDuplicateEventNotificationRx,
dot3OamLoopbackControlTx,
dot3OamLoopbackControlRx,
dot3OamVariableRequestTx,
dot3OamVariableRequestRx,
dot3OamVariableResponseTx,
dot3OamVariableResponseRx,
dot3OamOrgSpecificTx,
dot3OamOrgSpecificRx,
dot3OamUnsupportedCodesTx,
dot3OamUnsupportedCodesRx,
dot3OamFramesLostDueToOam
}
STATUS current
DESCRIPTION
"A collection of objects providing the statistics for the
number of various transmit and recieve events for OAM on an
Ethernet like interface. Note that all of these counters must
be supported even if the related function (as described in
dot3OamFunctionsSupported) is not supported. "
::= { dot3OamGroups 3 }
]] The compliance is not specified in group definitions.
MBS: Its one of the mandatory groups - what else are you looking for.
%% Oops, overlooked it, sorry.
<<text deleted>>
dot3OamErrFrameEventGroup OBJECT-GROUP
OBJECTS { dot3OamErrFrameWindow,
dot3OamErrFrameThreshold,
dot3OamErrFrameEvNotifEnable
}
STATUS current
DESCRIPTION
"A collection of objects for configuring the thresholds for an
Errored Frame Event.
Each [802.3ah] defined Event Notification TLV has its own
conformance group because each event can be implemented
independently of any other. "
::= { dot3OamGroups 7 }
]] Put this info about 802.3af in the commentary section
MBS: Which section are you refering to exactly?
%% Put it in the section before the MIB module, that describes
%% the organization of the objects in the MIB module.
<<text deleted>>
END
Regards,
/david t. perkins
_______________________________________________
Hubmib mailing list
Hubmib@ietf.org
https://www1.ietf.org/mailman/listinfo/hubmib
- [Hubmib] Response to comments on OAM doc David T. Perkins
- [Hubmib] RE: Response to comments on OAM doc Romascanu, Dan (Dan)
- RE: [Hubmib] Response to comments on OAM doc Romascanu, Dan (Dan)
- RE: [Hubmib] Response to comments on OAM doc Romascanu, Dan (Dan)
- RE: [Hubmib] Response to comments on OAM doc Matt Squire
- [Hubmib] RE: Response to comments on OAM doc Matt Squire
- [Hubmib] RE: Response to comments on OAM doc Romascanu, Dan (Dan)