[EFM-OAM] Notes from todays call
Participants: David Law, Ben Brown, Matt Squire
We focused on Clause 57, Sections 57.1-57.3, with the intent to identify non-editorial issues with Draft 1.414. There weren't a great deal of non-editorial issues discovered.
The following were discussed:
------------------------
OAM terms. In the opening paragraph, OAM is used to refer to both "generic OAM" and "IEEE 802.3ah OAM". It was suggested that we rework the suggestion along the lines of "In general, OAM does xyz... This clause defines IEEE 802.3 OAM which does abc... Henceforth, the term OAM will refer to the OAM mechanisms of this clause..."
Ben will provide a comment and suggested text.
-------------------------
Simultaneous loopback. The draft discusses "simultaneous loopback commands" in 57.2.8.1 (P121, L35). Its difficult to exactly discern what "simultaneous loopback commands" mean to someone not yet intimately familiar with the specification. Its difficult to provide specifics for the definition via something like a state machine because this is OAM client behavior, and we have purposefully stayed away from defining state machines for OAM client behavior. It was suggested that we re-word the paragraph so that we RECOMMEND that the OAM client does XYZ based on ABC (i.e. how to detect and react to simultaneous loopback commands). And that if they don't do that, certain bad things may happen.
Matt will provide a comment and suggest text.
-------------------------
Timestamps. We now have timestamps in the event frames and in the event TLVs. My personal recollection (and no one remembered otherwise) was that we weren't going to timstamp on transmission, but rather allow the receiver to timestamp on reception if they thought it was important. It seems like we reversed our previous position, and went timestamp happy. This also seemed to not be consistent with Clause 30.
Matt to follow-up with Kevin and anyone else who may remember how/why we ended up with the event timestamps all over. Anyone have a recollection?
--------------------------
Information PDU processing. Currently, every time an Information PDU is received, the receiver OAM client has to parse and process the whole thing so that differences in configuration can be detected. It was suggested that we add a revision number to the Information PDU (or TLV) so that the receiver can just look at the revision number to know if something has changed or not, and thus eliminate wasted processing.
Matt to provide comment and suggest text.
--------------------------
802.1/802.3. There seem to be some underlying layering issues between 802.1 and 802.3. In particular, we discussed the following issues:
- 802.1ad, where different MACs may be used for all reserved addresses, including OAM and LACP. The general consensus of the <few> people on the call wasn't in favor of tunneling OAM or LACP across the WAN as they are currently link-level protocols and there can be hardware out there that will swallow up these MAC addresses and not let the MAC client see them.
- 802.1ab and layering, with respect to OAM, PON, future 802.3 work. Seems like 802.1ab sits in the middle of 802.3, below the aggregation layer. How does that affect OAM, PON, and future TBD 802.3 work when 802.1 can sit in the middle of it?
David to follow up with Bob to see if we can't get some better coordination between .3 and .1 on the layering issues.
-----------------------------