Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-li-lb-07.txt

From: Hejia <[email-masked]>
Date: Thu, 20 Oct 2011 20:17:58 +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-mpls-tp-li-lb-07.txt

Reviewer: Jia He

Review Date: October 19, 2011

IETF LC End Date: 

Intended Status: Standards Track

Summary:

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

Comments:

The title indicates that the draft defines lock and loopback functions for
MPLS-TP. However, most parts in the draft use MPLS, e.g. MPLS networks, MPLS
OAM, MPLS Sections. Please check through the whole draft and make necessary
changes to keep consistent. 

Major Issues:

Minor Issues

1) Clarification required on "updates RFC 6371"

Section 1.1 gives clarifications on how it updates Section 7.1.1 of RFC
6371. 

"  The mechanism defined in this document requires that a lock

   instruction is sent by management to both ends of the locked

   transport path and that the Lock Instruct message does not require a

   response.

"

IMHO, only the latter part of the text above, i.e. "the Lock Instruct
message does not require a response", is related to Section 7.1.1 of RFC
6371 and indeed an update. The former part seems to be covered already in
Section 7.1 of RFC 6371 by the following description. What has been updated?
Could the authors give some clarifications?

"

   Note that it is also possible to administratively lock (and unlock)

   an MPLS-TP transport path using two-side provisioning, where the NMS

   administratively puts both MEPs into an administrative lock

   condition. In this case, the LKI function is not required/used.

"

BTW, according to Section 7.1 of RFC 6371 (the above text), LKI function is
not required/used when two-side provisioning by NMS is used. Is this true or
not in this draft? 

2) Section 3 gives the description below:

"

   To properly lock a transport path (for example, to ensure that a

   loopback test can be performed), both directions of the transport

   path must be taken out of service so a Lock command is sent to the

                                ^^^^^^^^^^^^^^^^^^^^^^^^^

   MEPs at both ends of the path. This ensures that no traffic is sent

   ^^^^^^^^^^^^^^^^^^^^^^^^

   in either direction. Thus, the Lock function can be realized entirely

                                                 ^^^^^^^^

   using the management plane.

   ^^^^^^^^^^^^^^^^^^^^^^^

"

followed by 

"

...In order to provide additional coordination, an LI OAM message can
additionally be sent.

                                                        ^^^^^^^^^^

"   

, which gives an impression that LI OAM message is optional when a lock
command is sent to both ends of a transport path. 

Besides, RFC 6371 indicates that LKI function is not required/used when
two-side provisioning by NMS is used, which is already pointed out in Issue
1).

However, Section 6.1 has the following description:

"

   As soon as the transport path has been locked, the MEP MUST send an

                                                 ^^^^

   LI message targeting the MEP at the other end of the locked transport

   path. 

"

, which indicates LI MUST be sent. Does it contradict with Section 3 or RFC
6371?    

3) Section 2.2 has the following term

3.1) MPLS-TP LSP: Bidirectional Label Switch Path

It is not proper to regard MPLS-TP LSP as "Bidirectional Label Switch Path"
since MPLS-TP LSP can be unidirectional (p2p, p2mp) as well. 

3.2) Transport path: MPLS-TP LSP or MPLS PW

MPLS PW or MPLS-TP PW? 

What about "MPLS-TP LSP or PW"?

4) Section 6.1

"  - If the transport path can be identified, but there is no return

     path (for example, the transport path was unidirectional) then the

     lock cannot be applied by the receiving MEP.

"

Is this applicable for LB function or LI function? 

To my understanding, this is prerequisites for LB function but not
necessarily for LI function since Lock Instruct message does not require a
response. 

Nits:

1) Section 1, the second paragraph, s/applied to to Label Switched
Paths/applied to Label Switched Paths,

2) Section 1, the fourth paragraph, s/the transport is locked/the transport
path is locked

3) Section 4.1, the second paragraph, s/must e/must be

4) Section 4.1, the third paragraph, s/This possible for/This is possible
for

5) Section 5.1, the first paragraph, s/Associated Channel Header
(ACh)/Associated Channel Header (ACH)

That's all.

B.R.

Jia