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)?
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.
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.
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.
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?
Nits:
None - that are not captured in the comments above!
/Loa
--
Loa Andersson email: [email protected]
Senior MPLS Expert [email protected]
Huawei Technologies (consultant) phone: +46 739 81 21 64
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
