[Pce] Re: draft-ietf-pce-pcecp-interarea-reqs-03.txt

Hi,

Hot on the heals of JP's comment, here are my thoughts on this draft.

None of the issues is sufficiently large to warrant a respin before WG last 
call, but if you have time over the next two weeks it would be nice for 
people to have a clean copy to review immediately after San Diego.

Thanks,
Adrian

Minor
===
Section 3
   It is expected that a solution for a PCECP satisfies these
   requirements.
What do we mean here exactly?
I think that we mean...
   Any PCECP solution MUST satisfy the requirements of
   [RFC4657] and MUST either satisfy the requirements
   specified in this document of MUST be readily extensible
   to satisfy these requirements.
---
Section 5.1
I think you need to require a failure reason that says "can't compute 
intra-area path to destination"
---
Section 5.2
   Hence the
   response message MUST support the inclusion of the identifiers of the
   crossed areas and MUST allow identifying the corresponding path
   segments.
Can you add a few words to clarify? What you are asking for is that the 
returned path be segmented and marked so that it is possible to tell which 
pieces of the path lie within which area?
---
Section 5.4
Need to clarify the intent of the list of preferred PCEs. Is there a 
requirement that only these PCEs will be used? Is there a requirement that 
all of these PCEs will be tried before any other is tried? Is there a 
linkage between the preferred PCEs and the IGP areas?
although these questions do not impact on the bits and bytes of the protocol 
extensions that would be defined, they do change how the protocol procedure 
extensions will be defined, so you must say something here.
---
Section 5.6
I think that for completeness and to ensure that the protocol meets your 
requirements, you should provide a table of all of the options that you wish 
to be able to signal.
---
Section 5.6
   The response message MUST allow indicating the level of diversity of
   a set of computed loose paths.
There is something implicit in this sentence. You are saying that the level 
of diversity provided may be different from the level of diversity requested 
(if it was not different, you would not need to provide an indication of the 
actual diversity). I think this means that the diversity request can be 
exactly a request, not a demand.
So you need to clarify. Does the path computation request message have 
"desired diversity" and "required diversity" constraints as separate fields?
---
Section 5.7
There is a mention of AS-crossing. Is that in scope?
---
Section 5.7
How is the second bullet different from the first paragraph of section 5.1?
---
Do you need to add the ability to list areas that are to be explicitly 
excluded form the path?
---
Section 6
I think you are adding requirements for a few extra things to be 
visible/manageable through the MIB modules. Which things? Which MIB modules?
---

Nits
====

Title
The RFC Editor is still not ready to accept that MPLS and GMPLS are 
well-known terms, so the title needs to change to...

Path Computation Element Communication Protocol (PCECP) Specific 
Requirements for Inter-Area Multiprotocol Label Switching (MPLS) and 
Generalized MPLS (GMPLS) Traffic Engineering
---
Abstract
You need to expand the following acronyms in the abstract...
IGP
TE
LSP
LSR
---
Abstract
OLD
   In a multi-area network, topology visibility remains local to
   a given area, and a head-end LSR cannot compute alone an inter-area
   shortest constrained path.
NEW
   In a multi-area network, topology visibility remains local to
   a given area, and a head-end LSR cannot compute an inter-area
   shortest constrained path.
---
Abstract
I think you should add a sentence to explain where PCECP fits in. For 
example...
   One key application of the Path
   Computation Element (PCE) based architecture is the computation of
   inter-area TE-LSP paths.
   ** The PCE Communication Protocol (PCECP) is used to communicate
   computation requests from PCE clients to PCE servers and to return
   computed paths in responses.***
   This document lists a detailed set of PCECP specific requirements for
   support of  inter-area TE-LSP path computation.
---
Abstract
   It complements generic
   requirements for a PCE Communication Protocol.
s/generic/the generic/
---
Section 1
I suggest you remove this as the Gen Art reviewers keep objecting.
You have section 12 anyway.
---
Section 2
Add ERO
---
Section 3
OLD
    The main challenge with inter-area MPLS-TE
    relies actually on path computation.
NEW
    The main challenge with inter-area MPLS-TE
    lies in path computation.
---
Section 3
OLD
   Indeed the head-end LSR cannot
   compute a constrained path across areas, as its topology visibility
   is limited to its own area.
NEW
   Indeed the head-end LSR cannot
   compute an explicit path across areas, as its topology visibility
   is limited to its own area.
---
Section 3
   The generic requirements for a PCE Communication Protocol (PCECP),
   which allows a PCC to send path computation requests to a PCE and the
   PCE to sent path computation responses to a PCC, are set forth in
   [RFC4657].
s/sent/send/
---
Section 3
   Note that PCE-based inter-area path computation may require a
   mechanism for an automatic PCE discovery across areas, which is out
   of the scope of this document.
s/for an automatic/for automatic/
---
Section 4
OLD
   IGP hierarchy allows improving IGP scalability, by dividing the IGP
   domain into areas and limiting the flooding scope of topology
   information to area boundaries. A router in an area has full topology
   information for its own area but only reachability to destinations in
   other areas._ Thus, a head-end LSR cannot compute an end-to-end
   constrained path that traverses more than one IGP area.
NEW
   IGP hierarchy enables improved IGP scalability by dividing the IGP
   domain into areas and limiting the flooding scope of topology
   information to within area boundaries. A router in an area has full
   topology information for its own area, but only information about
   reachability to destinations in other areas. Thus, a head-end LSR
   cannot compute an end-to-end path that crosses the boundary of its
   IGP area.
---
Section 4
OLD
   A solution for computing inter-area TE-LSP path currently relies on a
   per domain path computation ([PD-COMP]). It is based on loose hop
   routing with an ERO expansion on each ABR. This can allow setting up
   a constrained path, but faces two major limitations:
   - This does not allow computing an optimal constrained path;
   - This may lead to several crankback signaling messages and
     hence delay the LSP setup, and also invoke possible alternate
     routing activities.
NEW
   A current solution for computing inter-area TE-LSP path relies on a
   per domain path computation mechanism ([PD-COMP]). It is based
   on loose hop routing with an ERO expansion on each ABR. This
   allows an LSP to be set up following a contrained path, but faces two
   major limitations:
   - This does not guarantee the use of an optimal constrained path;
   - This may lead to several crankback signaling messages and
     hence delay the LSP setup, and may also invoke possible alternate
     routing activities.
---
Section 4
OLD
   The PCE based architecture [RFC4655] is well suited to inter-area
   path computation, as it allows overcoming the path computation
   limitations resulting from the limited topology visibility, by
   introducing path computation entities with more topology visibility,
   or by allowing cooperation between path computation entities in each
   area.
NEW
   The PCE based architecture [RFC4655] is well suited to inter-area
   path computation, as it allows the path computation limitations
   resulting from the limited topology visibility to be overcome by
   introducing path computation entities with more topology visibility,
   or by allowing cooperation between path computation entities in each
   area.
---
Section 4
OLD
   - Single PCE computation: The path is computed by a single PCE that
     has topology visibility in all areas and can alone compute an end-
     to-end optimal constrained path.
NEW
   - Single PCE computation: The path is computed by a single PCE that
     has topology visibility in all areas and can compute an end-to-end
     optimal constrained path on its own.
---
Section 4
   - Multiple PCE computation with inter-PCE communication: the path
     computation is distributed on multiple PCEs, which have partial
     topology visibility. They compute path segments in their areas of
     visibility and collaborate with each other so as to arrive at an
     end-to-end optimal constrained path. Such collaboration is ensured
     thanks to inter-PCE communication.
s/communication: the/communication: The/
s/their areas/their domains/
---
Section 5.1
Missing paragraph break after first paragraph.
---
Section 5.3
s/one ore more/one or more/
---
Section 5.4
Missing paragraph break between paras 2 and 3
---

Section 5.5
Missing paragraph break
---
Sections 10.1 and 10.2
Some non-ASCII characters crept in thanks to MS smart-quotes.
---
Section 10.2
[ID-RSVP] is not cited in the main text.
---
Section 10.2
Missing reference for [METRIC]
--- 

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce