Subject: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt

From: Lizhong Jin<[email-masked]>
Date: Tue, 14 Aug 2012 21:34:21 +0800

Hello, 

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and sometimes 
on special request. The purpose of the review is to provide assistance to 
the Routing ADs. For more information about the Routing Directorate, 
please see http://www.ietf.org/iesg/directorate/routing.html 

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF Last 
Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft. 

Document: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt 
Reviewer: Lizhong Jin
Review Date: Aug, 14th, 2012 
IETF LC End Date: Aug, 20th, 2012
Intended Status: Standard track

Summary:
1.I have some minor concerns about this document that I think should be 
resolved before publication.

Comments:
Basically, this document is well written and I believe the mechanism has 
been implemented and deployed in real networks. There are only some parts 
of the document that need to be clarified to avoid misunderstanding.

Major Issues:
No major issues found.

Minor Issues:
2.2.  Abstract Defect States 
A PW forward defect indication received on PE1 impacts the ability 
of PE1 to receive traffic on the PW. 
[Lizhong] "PW forward defect" only refers to one mechanism above, should 
it be "PW receive defect"?
 
4.1. Use of Native Service (NS) Notification 

    - Sending of AIS frames from the local MEP to the MEP on the 
remote PE when the MEP needs to convey PE receive defects, and when 
CCM transmission is disabled. 
[Lizhong] "PE receive defects" refer to PE AC receive defects or both AC 
and PE receive defects?
 
    - Suspension of CCM frames transmission from the local MEP to 
the peer MEP on the remote PE to convey PE receive defects, when 
CCM transmission is enabled. 
[Lizhong] "PE receive defects" refer to PE AC receive defects or both AC 
and PE receive defects?

4.2. Use of PW Status notification for MPLS PSNs 

There are also scenarios where a PE carries out PW label withdrawal 
instead of PW status notification. These include administrative 
disablement of the PW or loss of Target LDP session with the peer 
PE. 
[Lizhong] There is another PW/AC status signaling method by using label 
withdraw method when PW status notification is not supported. Is it 
intentionally ignored?

4.3. Use of BFD Diagnostic Codes 

When using VCCV, the control channel (CC) type and Connectivity 
Verification (CV) Type are agreed on between the peer PEs using the 
OAM capability sub-TLV signaled as part of the interface parameter 
TLV when using FEC 129 and the interface parameter sub-TLV when 
using FEC 128. 
[Lizhong] the "OAM capability sub-TLV" refer to "VCCV interface parameters 
sub-TLV", right? Suggest to align with terminology in RFC5085.

5. Ethernet AC Defect States Entry or Exit Criteria 
[Lizhong] context of AC receive/transmit defect entry is duplicated with 
that in section 2.2. Is it possible to make the context more simple, 
either in section 2.2 or 5.1?

6. Ethernet AC and PW Defect States Interworking 
[Lizhong] RFC2119 words should be used in this section, e.g, "must" should 
be "MUST".

6.1. PW Receive Defect Entry Procedures 
[Lizhong] this section does not describe the mechanism to enter PW receive 
defect state, is it same with that in section 2.2?

Further, when PE1 enters the Receive Defect state, it must assume 
that PE2 has no knowledge of the defect and must send reverse 
defect failure notification to PE2. For MPLS PSN or MPLS-IP PSN, 
this is done via either a PW Status notification message indicating 
a reverse defect; or via VCCV-BFD diagnostic code of reverse defect 
if VCCV CV type of 0x08 had been negotiated. 
[Lizhong] why CV type of 0x20 is missed here?

6.2. PW Receive Defect Exit Procedures 
[Lizhong] this section does not describe the mechanism to exit PW receive 
defect state?

If PW receive defect was established via notification from PE2 or 
via loss of control adjacency, no additional action is needed, 
since PE2 is expected to be aware of the defect clearing. 
[Lizhong] the above description is incorrect in this section. The exit of 
PW receive defect should be described, not enter of PW receive defect.

6.3. PW Transmit Defect Entry Procedures 

- If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is 
used for fault notification, PE1 must transmit E-LMI asynchronous 
STATUS message with report type Single EVC Asynchronous Status 
indicating that PW is Not Active. 
[Lizhong] shouldn't the entry of PW transmit defect be signaled to remote 
PE? I do not see such text here.

6.4. PW Transmit Defect Exit Procedures 

- If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must 
transmit E-LMI asynchronous STATUS message with report type Single 
EVC Asynchronous Status indicating that PW is Active. 
[Lizhong] same comment as for previous section, shouldn't the exit of PW 
transmit defect be signaled to remote PE? I do not see such text here.

6.5. AC Receive Defect Entry Procedures 

When Native Service OAM mechanism is supported on PE1, it can also 
use the NS OAM notification as specified in Section 4.1. 
[Lizhong] is there any relationship between notification mechanism in CE 
domain and mechanism in PE domain. I mean if the AC uses NS OAM to detect 
defect in CE domain, does NS OAM between PEs have any priority to apply?

Nits:
There are some nits that need to resolve. Please check link: 
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt

Regards
Lizhong