[RTG-DIR] 答复: [Pce] RTG Area review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures

[Quintin zhao <[e-mail]>]

Dear Loa,



Thanks for your detailed review for this draft. Please see  our replies in-line. We have incorporated your comments into the new version attached here. Please let us know if you have further comments.



Quintin

-------------------------------------------------------------------------------------------------------------------------------------------
On Wed, May 14, 2014 at 11:47 AM, Loa Andersson <[e-mail]<mailto:[e-mail]>> wrote:
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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

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-pce-pcep-inter-domain-p2mp-procedures-06
Reviewer: Loa Andersson
Review Date: 2013-05-14
IETF LC End Date: couldn't find
Intended Status: Experimental

Summary:

This document is basically ready for publication, but has nits that should be considered

prior to publication.

Comments:
1. I like that an experimental RFC (for once) actually describe an
   experiment

2. The abstract says:
  "The ability to compute paths for constrained point-to-multipoint
   (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across
   multiple domains has been identified as a key requirement for the
   deployment of P2MP services in MPLS and GMPLS-controlled networks."

   Where was this defined (reference)?

RFC5671 but implicitly (section 3)


3. There are a couple of cases where words that ae in the 2119-language
   appear in the document in lower cases, please check if this is
   intended or if the normative language are intended.

4. For the terminology section it would be good to know which terms
   that are defined in this document for the first time, otherwise
   please give a reference to where to find the definition.

We will append terminology section -
   Terminology used in this document is consistent with the related
   MPLS/GMPLS and PCE documents [RFC4461], [RFC4655], [RFC4875],
   [RFC5376], [RFC5440], [RFC5441], [RFC5671] and [RFC5862].

   The additional terms Core-Tree, Leaf Domain, Path Tree, Path Domain
   Sequence, Path Domain Tree, Root Domain, Sub-Tree and Transit/branch
   Domain are further defined below.


5. This is possibly an oxymoron comment, but it seems to me that the
   problem statement (section 3) is too focused on describing how hard
   it is to solve the inter-domain P2MP path computation, rather than
   to describe what the problem are.
We will rename the section as Examination of Existing Mechanisms.


6. I'm a little bit concerned about the requirements, it seems that
   they are very close to design criteria.

7. Section 7.1 the concept "entry boundary nodes" are used, is this
   concept defined anywhere? For example from figure 2 I understand
   that L, W, P and T are entry boundary nodes, while D and E are not.

Entry boundary nodes is defined in 5441 etc.
But we specifically mean entry boundary node of the leaf/destination domain and this is L,W,P & T and not D & E.


8. I think it would be good have an H-PCE entry in the terminology
   section.

The document is fairly easy to read and quality is good, there is
sometimes a wish from the authors to bring through how dammed hard this
problem is to solve - they might be right - but there is a risk of
creating a lot of trees that stops you from seeing the forrest (or
maybe the other way around).

Major Issues:

None

Minor issues:

It seems that the document should lead up to a set of protocol
extensions, but in the the only change is to add the C-bit, right?

On the wire changes (message and object encoding) is limited.
There are necessary procedure changes.


Nits:

None - that are not captured in the comments above!


/Loa

--


Loa Andersson                        email: [e-mail]<mailto:[e-mail]>
Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>
Huawei Technologies (consultant)     phone: [phone]

_______________________________________________
Pce mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pce