Subject: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework

From: Julien Meuric <[email-masked]>
Date: Tue, 01 Feb 2011 00:54:11 +0100

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-ccamp-mpls-tp-cp-framework-05
Reviewer: Julien Meuric
Review Date: 31 January 2011
IETF LC End Date: 31 January 2011
Intended Status: Informational

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

*Comments:*
This document is clearly written and easy to understand, even if the 
reader does not go over the numerous references.

*Major Issues:*
No major issues found.

*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... 
information".
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.
----------

*Nits:*
----------
Section 1.2
s/over LSP based/over LSP-based/
----------
Section 2.3
s/customer/client/
----------
  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 4.1.4.1 (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 
[TP-SURVIVE], is/
----------
Section 4.2.1.2
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 
theoretical)
----------
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/
----------

Regards,

Julien