| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
"Martin, David [CAR:QW18:EXCH]" wrote:
Matt,
Thanks for the recap.
Re timestamps> I would vote for timestamp on generation from an accuracy perspective. If it was only done on reception there might be variations due to queuing (?) From reading (just) the first 3 sub-clauses I thought the timestamp was on generation - OAM_CTL.request / local_time_stamp primitive.
Re 802.1ad> I agree that tunneling link OAM through the WAN is not desirable. If the CE-PE link OAM is tunneled then the PE has no view of the access link integrity, beyond what's available today. Keeping it as link (PE accessable) complements the various WAN OAM activities (i.e. MEF service OAM for PE-PE, and ITU-T SG13/Q.3)
Did Norm Finn ever explain his claims about EFM OAM being a problem / not working with 802.1ad per the flag Ben threw a couple of weeks ago?
...Dave
David W. Martin
Nortel Networks
dwmartin@ieee.org
+1 613 765-2901 (esn 395)
~~~~~~~~~~~~~~~~~~~~~~~~~~-----Original Message-----
From: Matt Squire [mailto:MSquire@hatterasnetworks.com]
Sent: Thursday, April 17, 2003 2:06 PM
To: stds-802-3-efm-oam@ieee.org
Subject: [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.
-----------------------------
begin:vcard n:Brand;Richard C. tel;work:(408) 495 2462 : ESN 265 2462 x-mozilla-html:FALSE org:Advanced Technology Investment adr:;;4655 Great America Pkway;Santa Clara;Ca.;95054; version:2.1 email;internet:rbrand@Nortelnetworks.com title:Director, Network Architecture & Applications fn:Richard C. Brand end:vcard