[PWE3] comments on draft-ietf-pwe3-mpls-eth-oam-iwk

[Yaakov Stein <[e-mail]>]

I apologize for taking so long to get to review this document,
and must admit that I did not have the time to carefully review all of the defect entry and exit criteria.

But here are my comments :

General comment - The lack of definite and indefinite articles makes the text hard to read.  For example, in section 1.2 all of the statements of the type “AC receive defect …” would be more understandable if the text said “An AC receive defect …” Similarly “there is need” -> “there is a need”. In 3.3 “ PW defect is detected” assumedly means “a PW defect is detected”. And so on throughout the document.

In section 1 “When an Ethernet AC is an Ethernet PHY” should be “When an Ethernet AC is a single Ethernet link”.


“In addition, scalability constraints may not allow running proactive monitoring, such as CCMs with transmission on”.

I am not sure I understand the sentence. Does it mean “In addition, scalability constraints may not allow proactive monitoring such as CCMs” ?


Figure 1  please update to corrected version in oam-msg-map, this version has several typos and is incorrect !

Other CCM interface status TLVs will not be used  ->  Other CCM interface status TLV values will not be used
(There is only one CCM interface TLV but it can take several values)

“could point to problems associated with PE2’s inability to transmit” this should be "problems with its ability to transmit"
(a problem with inability to transmit would assumedly mean that the PE is functioning perfectly)

3.1  However, with the completion of Ethernet OAM work  -  this remark is so old that it should be removed.

“and when CCM transmission is configured not to be turned ON”  suggest saying “and when CCM transmission is disabled”.
I have a question about this – although AIS is more crucial when CCM is disabled, are you disallowing it when CCM is enabled ?
The second option, suspension of CCM frames of the downstream MEP, leads to uninhibited alarm propagation.

In section 3.2 forward and reverse defects are defined as in oam-msg-map.
However, the draft sometimes uses the term “forward defect indication” and sometimes “forward defect notification”. Is there a difference ?
Also, in section 5.6 it is stated that the forward defect notification is cleared. Shouldn’t this be “the forward defect is cleared” ?
On the other hand, the term “reverse defect notification” is consistently used (not indication), except  in Section 5.1 where  we have the term “reverse defect failure notification”.

3.2 first paragraph has 2 SHOULDs. Why is LDP status messaging not a MUST (that is my interpretation of 4447)?.
What is done in other cases if diag codes are NOT used ?
(The text in oam-msg-map states that if LDP is not used then some alternative method MUST be used.)

4.1 iss removed -> is removed    if AIS was resulted -> if receiving AIS resulted

“period indicated by previously received AIS” assumedly refers to the AIS transmission period carried in the AIS PDU.
Missing a single AIS should not be taken as an indication that AIS is cleared – one should probably wait 3 ½ transmission period times.

Similarly in 4.2, I think you want to clear the transmit defect upon receiving CCMs with RDI cleared, not based on not receiving CCMs with RDI set as stated.

In all of section 5, can the clumsy “is (not) configured to be turned on” be replaced with “is (dis)abled” ?


In 5.1 “When Native Service OAM mechanism is supported on PE, it can also use the NS OAM notification” – is this instead or in addition to PW status ?


Section 5.6  For consistency I believe that the second paragraph should state that when LDP has been used LDP status messaging MUST be used,
rather than the convoluted “When NS OAM is not supported and MPLS PSN” (and not even mentioning LDP!).

Section 8 – I suggest that you harmonize the security section with that of oam-msg-map.

In the references  802.1ag needs updating from D8.1 to the published version

Appendix – newer versions of Y.1731 define additional functions.


Y(J)S