Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-cc-cv-rdi-05.txt

From: Hejia <[email-masked]>
Date: Mon, 18 Jul 2011 21:48:50 +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. 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-mpls-tp-cc-cv-rdi-05
Reviewer: Jia He
Review Date: July 17, 2011
IETF LC End Date: 
Intended Status: Standards Track

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

Major Issues:

A detailed description of how CC and CV functions are interleaved is missing.  

For example, if a MEP detects mis-connectivity defect via CV packets, will it drive the BFD state change? How to? 
- How does CV function contribute to the BFD state machine? How to deal with the impact on the state machine which might be caused by the possible different defect detection time applied to CV and CC functions? Section 3.7.5 only describes CC state machine. IMHO, a CC and CV interleaved BFD state machine should be defined instead.  
- How will it communicate the state change with the peer MEP? Section 3.6 sets the following rule
"All BFD state changes and P/F exchanges MUST be done using CC packets. P/F and session state information in CV packets MUST be ignored. " 
Does it mean the BFD state change caused by mis-connectivity (detected by CV packet) should be communicated via CC packet in the backward direction to the peer MEP instead of CV packet itself? But the diagnostic code is read from CC and CV packets respectively?

Minor Issues

Some of the following "Minor Issues" are more questions/clarifications for my understanding and suggestion rather than "pure" issues.

1) Abstract, in the middle of the second paragraph, states
"Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. "
"Integrity of routing" is used ambiguously here. To my understanding, CV verifies that the source and sink of an LSP is correctly connected but does not contribute to the check of routing. IMHO, "routing" involves more than the connectivity between source and sink of an LSP. What about the following change?  

"Connectivity verification monitors the integrity of the connectivity of the label switched path between sink and source for any mis-connectivity issues. "

2) Abstract, at the end, states
"This document specifies methods ... using Bidirectional Forwarding Detection. "
However, the extensions of BFD is also specified in this document. To be accurate, how about appending the sentence with "and its extensions" at the end?  

3) Section 3.2(CC,CV, and RDI overview), at the end, only describes the RDI function communicated via BFD CC message (diagnostic code "1" or "5"). Although the indication of mis-connectivity defect is described at the end of Section 3.7.3 (Defect entry consequent action) requiring a new diagnostic code to be assigned by IANA, to keep integrality, it is better to add the similar description in Section 3.2.

4) Section 3.4 and Section 3.5 use "MPLS BFD CC (or proactive CV) Message format" as the title, which might cause confusion since the whole document is talking about MPLS-TP CC/CV/RDI functions. To eliminate ambiguity, what about using "MPLS-TP CC Message format" and "MPLS-TP proactive CV Message format" instead? 

5) The titles of Figure 2 and Figure 3 use "MPLS CC Message" and "MPLS CV Message" respectively. To be aligned with the other part of this document, it is proposed to change MPLS to MPLS-TP in the titles.

6) Section 3.7 states
"For LSPs, SPMEs and sections this is GAL/G-ACh encapsulated BFD using the code points specified in section 3.1. For PWs, this is G-ACh encapsulated BFD using the code points specified in section 3.1. "
Since the usage of GAL in PW is currently under discussion (draft-ietf-pwe3-mpls-tp-gal-in-pw-01, draft-nadeau-pwe3-vccv-2-02) , is it possible to leave this issue open?

7) Section 3.7.2 Defect entry criteria
What is the relationship among these defect entry criteria? Does it reflect the order of priority? If yes, it is better to express this in the document explicitly.

Besides, in the middle of this section, it states

     4. Receipt of a session discriminator that is in the local database 
        but does not have the expected label (mis-connectivity defect).

What does the "expected label" indicate? The encapsulation of a LSP or a PW, etc.? Shouldn't it be checked at the first beginning?

8) Sections 3.5.1 ~ 3.5.3, Section/LSP/PW source MEP-ID
Does it cover SPME? Any difference? 

9) Is MEG ID used in this document? Section 4 lists "The MEG/MEP ID for the MEPs at either end of the LSP" as one of these configuration considerations.

Nits:

1) continuity check/Continuity Check, connectivity verification/Connectivity Verification, remote defect indication/Remote Defect Indication
The above are differently written (sometimes initials in capitals, sometimes not) throughout the document. Please check through the whole document and make alignment.

2) Section 1, typo
Both pseudo wires (PWs) and MPLS-TP label switched paths (LSPs) [12][12]..., [12] duplicates
As described in [13][13]..., [13] duplicates

3) Section 2, to keep alignment with the terminology definition of GAL in RFC5586
s/GAL Generalized Alert Label/GAL G-ACh Label/

4) Section 3.3, Figure 1 
According to the description of Figure 1, it illustrates the G-ACh encoding for BFD CC-CV-RDI functionality rather than Connectivity Verification only. To keep aligned, it is proposed to change the title of Figure 1 to "ACH Indication of MPLS-TP Continuity Check, Connectivity Verification and Remote Defect Indication"

5) Section 3.5.3, s/MPLS_TP/MPLS-TP/

6) Section 3.7.5, s/LKI/LKR/

That's all.

B.R.
Jia