[EFM] OAM recap...
Short recap of the 802.3ah OAM meetings held in Raleigh on 1/15.
We spent most of the morning reviewing the requirements/scope document.
The most controversial discussions were focused on the necessity of a
modal loopback function. The need for a 'ping' test was uncontested,
but the need to support a loopback mode where every frame was turned
around wasn't universal. In particular, there was the belief that we
could expand the 802.3 MIBs to count additional variables that would
provide function very similar to a BERT test but do so while still
in-service. It was decided that we would pursue this possibility
offline. Bob, Roy, Denny, and Rich have agreed to look into this
offline, with Roy and Bob defining a problem statement (i.e. why does
loopback do) and Denny and Rich looking into alternative non-intrusive
methods for reaching those goals. Others interested in helping in
either the problem definition or alternate methods should contact me and
I will put you in touch with the appropriate leads.
On link monitoring, we re-instated the 'polling' requirement that was
removed before the last meeting. The justification is that a minimal
set of variables will be periodically reported asynchronously, but that
troubleshooting will be done on-demand and will require the ability to
'get' a wide set of variables.
There was a little bit of discussion on the wording in the RFI
requirements, though the agreement on the intent was fairly universal.
I tried to change the wording of the RFI section to address the
concerns. The main point is that we agree that a station has to be able
to send OAM data even if the receive path is broken, but that higher
layers must not be able to access a undirectional link (because it would
interfere with protocols such as 802.1D bridging, as an example).
We then spent a few hours talking about the security requirements of
OAM. We agreed that privacy (ie encryption) was not a requirement of
OAM transport. We also agreed that authentication (private keys, shared
keys, etc.) was outside the scope of OAM. We had disagreement on
whether non-repudiation of OAM was required. Some folks wanted to use
OAM data for billing applications, and thus wanted some way to ensure it
wasn't tampered with and came from the right place. The feel of the
room was informally 7 against non-repudiation and 6 for
non-repudiation.
We discussed initialization issues as well. In particular, whether
there needed to be the ability to disable the MAC layer from user
transport if OAM initialization wasn't successful. The intent here was
that if the SP wanted OAM to be required on the link between the OLT and
the ONU, then if OAM wasn't detected on startup, the MAC layer wouldn't
come up. The main question seemed to be whether this option should be
embedded in 802.3 itself or in some management application that sits
above 802.3. The informal feel of the room was 10-6 in favor of
including some shut-off capability in the OAM initialization procedures.
Denny and Hiroshi presented the oam-in-frames and oam-in-preamble
presentations, with Kevin and Hiroshi also including some comparisons in
their presentations. Much debate on the transport as expected. No
clear direction from the room on a preferred transport method. We will
be taking up the transport discussion on the list - hopefully very
soon. We must make this decision for the March plenary!
There was discussion of OAM initialization (and initialization in
general) at the closing plenary. OAM needs to get with the copper track
and with the PON track to coordinate initialization procedures. Hugh,
Gerry, Howard, and myself will figure out how to best schedule the
initialization discussions before the next meeting.
In short, we made some progress but now must focus on the big issue at
hand - how do the OAM bits get from one end of the link to the other.
Please participate in these discussions as they progress on the list.
OAM is, for many people, a secondary goal in EFM, with PHY development
being the primary goal. However, as OAM will effect all PHYs, we need
greater participation in order to address the transport issue. I am
likely to attempt to schedule some time for OAM transport debates before
a larger audience than just the OAM group - all input is welcomed.
- Matt