[mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt

["Bhatia, Manav (Manav)" <[e-mail]>]

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 seehttp://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-rosetta-stone-12.txt
Reviewer: Manav Bhatia
Review Date: October 13th, 2013
IETF LC End Date: October 16, 2013
Intended Status: Informational
 
Summary:  This document is basically ready for publication, but has nits that should be considered prior to publication.

Comments: This document is built on top of terms already defined in different RFCs and ITU-T documents. The terms and definitions have already been reviewed so there is a trifle little that needs to be done there. Overall, the document looks good and ready for publication. Some of my comments can be 
 
Nits:

o) Please expand PW in either the Abstract or Sec 3.5

o) When explaining Control Plane (3.6) should we mention that it is possible to operate an MPLS-TP network without using a Control Plane?

o) In 3.7, it would be useful to mention that an important property of co-routed bidirectional path is that the forward and backward directions share fate. Similarly, in 3.1, we should mention that the forward and backward directions don't share fate.

o) 3.12 in the current text doesn't look very helpful. Can it be rephrased it to something like, "The equipment management function (EMF) provides the means through which an element management system (EMS) and other managing entities manage the network element function (NEF)."

o) 3.13 talks about Fault cause without explaining what a fault cause is. It took me some time to understand what was meant by "fault cause". Can the authors of the draft rephrase 3.13 in their own language to explain what they mean by a Failure. The current definition in the draft has been picked up as-is from ITU-T G.806

o) 3.14 talks about "inability of a function to perform a required action". Since this RFC-to-be is in the IETF domain, can this be rephrased to use a term like router/switch instead of a more esoteric "function". This is a general comment and applies to most of the definitions that have been copied from the ITU-T documents.

o) The last paragraph of 3.17 says the following:

"OAM packets are subject to the same forwarding treatment as the data traffic, but they are distinct from the data traffic."

In what sense are the OAM packets distinct from the data traffic? 

o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not been expanded in the document.

o) Sec 3.19 uses TCM without expanding it first.

o) In Sec 3.23, s/Tandem Connections/Tandem Connection

o) In 3.28.3, can the following text be added:

An LSP segment comprises one or more continuous hops on the path of the LSP.  [RFC5654] defines two terms.  A "segment" is a single hop along the path of an LSP, while a "concatenated segment" is more than one hop along the path of an LSP.

o) In 3.31, Isn't Operations Support Systems (OSS) a more common term than Operations Systems (OS)?

Cheers, Manav