MPLS Transport Profile (MPLS-TP) Control Plane Framework
RFC 6373

Note: This ballot was opened for revision 06 and is now closed.

(Stewart Bryant) Yes

(Adrian Farrel) Yes

Comment (2011-02-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Ben Campbell raised some minor points in his review to be cleaned up in the next revision.
Similarly, Julien Meuric raised some small issues.

=== Ben ===

Minor issues:

-- Section 2 (and subsections)

This section appears to be made up almost entirely of restatements of requirements that are normatively stated elsewhere. That takes up about 16 pages. Is that really necessary, other than to say which requirements apply to the control plane? You could do that by merely calling out the numbers of the requirements that apply from each document, and making notes when more explanation is needed. Since you explicitly state that the source documents are authoritative, then a careful reader will need to read those documents anyway. OTOH, a not-so-careful reader may not read the source documents, and therefore be misinformed if this document introduces any discrepancies.

-- Security Considerations:

Are you willing to assert that no new security considerations are introduced by the existing mechanism being used in this new context?

Nits/editorial comments:

-- IDNits returns errors and warnings. Please check.

-- The document lists 5 editors on the front page, and 8 authors in the author section. That's a bit on the high side. I have no opinion whether that is reasonable for this draft--I just call it out so others can decide.

-- Please number the tables.

-- The document makes inconsistent use of references. For example, you jump between the forms of "... as defined in document[xxx]", "... as defined in document, see [xxx]", and "as defined in [xxx]". More consistency would make for easier reading. I personally prefer the first form, and find the second form disruptive to the flow of reading.

-- Section 1, paragraph 1: "(MPLS-TP) is being defined"

Be careful with time-sensitive statements such as this. An RFC lives forever, and this statement may be nonsensical to readers in e future. At least qualify it with something like "at the time of this writing..."

-- Section 1, paragraph 2: "as defined by the ITU-T"


-- Section 1.2, numbered list:

This is really just normal information, not a sequence. I suggest paragraph form, or a bullet list if you really need a list format.

Please put space between the list entries. A long list like this is difficult to read without some white space.

Please expand acronyms on first use. There are a number of unexpanded acronyms in this section.

-- section 2, first paragraph: "The requirements are summarized in this section, but do not replace those documents. If there are differences between this section and those documents, those documents shall be considered authoritative."

I assume that makes this entire section non-normative, even though it uses terms like "must" (albeit non-capitalized). It might be good to say that explicitly, as readers may not notice the lack of capitals.

-- section 2.1, req 38:

Do you expect to keep "requirement removed" in the final RFC?

-- ..., req 39:

Which documents are you treating as authoritative for the purpose of this document, the ITU or IETF documents?

-- req 52:

The referenced requirement says it MUST be possible to require 100% of traffic on the protected path. "Up to 100%" is not the same thing

-- req 95:

Is that a requirement, or an observation?

-- req 100:

Is that a requirement, or an observation?

-- req 101:

Is that a requirement, or an observation?

-- section 4.1.1: "Out-of-band, in-fiber"

You are talking about any scenario using the same physical network, right? Is the concept limited to fiber in any way?

-- section 4.1.1, last paragraph: "Some expect the G-ACh to be used extensively..."

Who expects it? Can you say something more concrete?

-- 4.1.5, 1st paragraph: "... it is deprecated, and must not be used for MPLS-TP."

Do you mean that to be normative?

-- 4.1.9, last paragraph: "Recovery for MPLS-TP LSPs as discussed in [TP-SURVIVE], is signaled..."

Missing comma before "as"

--, list:

Please use vertical white space between list entries


There are lots of statements of the form "must be possible". Do you mean anything in this section to be normative?

-- 4.4.1, last paragraph: "This work will serve as the foundation..."

The referenced work, or this draft? (Similar question for 4.4.5)

Also, there's an odd mid-sentence paragraph break here in the PDF version.

-- 4.4.5

This whole paragraph is very time sensitive, and asserts a number of things that may no longer be true at some point in the future.

-- 5.3, 2nd paragraph: "See the table in the section above"

Please give a section or table number cross reference.

-- 5.3.2, third paragraph: "it may be required that bidirectional traffic follows congruent paths."

"May be required" is pretty vague. Are you talking about requirements on the protocol as listed in this document, or something else? (who may require it?)

=== Julien ===

*Minor Issues:* (leaving out acronym expansion or references to add 
already highlighted by the AD)
Section 1.3
Quoting Adrian (by the way: congratulations!): "A reference to 
draft-ietf-mpls-tp-uni-nni might be appropriate to aid the discussion of 
UNIs and NNIs." Indeed, but it requires more than a reference: since the 
aforementioned I-D only defines "service interfaces", a little 
elaboration on the use of "NNI" in draft-ietf-ccamp-mpls-tp-cp-framework 
is needed.
Section 2.1
Requirement 17 looks like a tautology. Requirement 19 in RFC 5654 
clarifies the intend, but I am not sure it is needed here more than "A 
control plane must not be required to support coffee making".

Requirements 21 and 22 refers to "homogeneous" and "non homogeneous" 
domains, but I do not think it is defined. Would my domain with all my 
640 Mb/s switching capacity nodes be homogeneous?

I believe requirement 24 also covers 27.C from RFC 5654.

Requirement 39 mentions ASON: I thought the scope of ASON was 
circuit-switched technologies, has it been extended for packet-switched?

Requirement 62 states "this should be the default": I guess "this" 
refers to bidirectional, but I believe the wording should be improved.

Requirement 65 says "the control plane may support extra-traffic": not 
sure what is means (extra traffic over the control network?).
Section 4.2.1
It is consistent to section 2 of RFC 5951: an explicit reference could 
be added, especially when considering the title of that RFC...
Section 4.3 and 5.2
Not sure about the dashes following the numbers: should not they be in 
the right column instead of the left one?

It is a bit surprising to see explicitly "proper vendor implementation" 
while it is should be implicit for any standard specification...
Section 5.3.2: "If the control plane is physically separated... 
I do not believe this paragraph is needed here: no other section 
mentions that sub-case (which might be in the scope of the ForCES WG).
Section 4.2.1 focuses on "Management Plane Support" within the "4. TE 
LSPs" section. The same kind of paragraph is expected in the "5. 
Pseudowires" section but is currently missing.

Section 1.2
s/over LSP based/over LSP-based/
Section 2.3
  Section 4.1.1
s/control (and management) planes/control (and management) plane(s)/
Section 4.1.2
s/and consequently, MPLS-TP uses/and consequently MPLS-TP, uses/
s/control (and management) planes/control (and management) plane(s)/
Section (interesting concepts)
s/(PCE) Based approaches/(PCE)-based approaches/
s/PCE requests and responses/requests to and responses from PCE/
Section 4.1.9
s/LSPs as discussed in [TP-SURVIVE], is/LSPs, as discussed in 
s/the life, (traffic hit/the life (traffic hit/
Section 4.4.4
s/but nonetheless, must/but nonetheless must/
Section 4.4.5
s/OAM related/OAM-related/ (twice)
Section 4.4.6
s/Diffserv enable/Diffserv-enabled/transport
s/Diffserv related/Diffserv-related/
Section 4.4.8
s/entity related/entity-related/
Section 5.3.1
s/to be, theoretically, a straightforward exercise/to be a 
straightforward exercise/ (unless there is a strong reason to keep it 
Section 5.3.5
s/transport service require OAM/transport service requires OAM/
s/performance related monitor/performance-related monitor/
Section 6
s/MPLS and GMPLS related/MPLS- and GMPLS-related/

(Jari Arkko) No Objection

Comment (2011-02-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Ari Keränen helped me review this, and he said the following:

Various acronyms throughout the document need expanding on their first use, for example:

      3) MPLS PWs are used by MPLS-TP including the use of targeted LDP
         as the foundation for PW signaling [RFC4447]; and OSPF-TE,
         ISIS-TE or MP-BGP
         and ISIS-TE [RFC5307][RFC5316].  ASON signaling and routing
         summarized information (such as SRLGs or reachability) between
         functional components which include MEs and MEGs as
         proactive CC-V function enabled, the control plane must support
         transmission rate and PHB class associated with the LM OAM

    Figure 1. End-to-End MPLS-TP Control Plane Reference Model

The P1, P2, and Pa are missing from the legend.

2.1. Primary Requirements

     38. Requirement removed.

Is it necessary to have it here then? Management Plane / Control Plane Ownership Transfer

   In networks where both control plane and management plane are
   provided, LSP provisioning can be bone either by control plane or
   management plane.


(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Russ Housley) No Objection

Comment (2011-02-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  Please consider the comments from the Gen-ART Review by Ben Campbell
  on 31-JAN-2011.  You can found the review at:

(Tim Polk) No Objection

(Dan Romascanu) No Objection

Comment (2011-02-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
in section 4.2.1 s/MIBs/MIB modules/

(Robert Sparks) No Objection

(Sean Turner) No Objection