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

["LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>]

Hi Adrian

Thanks for the review.
A new revision accounting for your comments will be posted next week.
See inline for some comments,


> -----Message d'origine-----
> De : Adrian Farrel [mailto:[e-mail]] 
> Envoyé : samedi 28 octobre 2006 13:28
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [e-mail]
> Objet : 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.

Humm this sounds a bit too vague. Actually here we request for specific PCEP procedures.
What about:
"It is expected that PCECP procedures be defined 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"

This is a good point:
What about: 
"In situations where an intra-area path is requested while there is no feasible intra-area path, the response message MUST allow indicating that an intra-area path cannot be found."

> ---
> 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?

Yes it is.
Would the following clarify?
"Hence the response message MUST allow identifying the crossed areas. Also the response message MUST allow segmenting the returned path and marking each segment 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.

Here is the requirement we have actually in mind:

"In case of multiple-PCE inter-area path computation, a PCC may want to indicate a preferred list of PCEs to be used, one per area. 
In each area the preferred PCE should be tried before another PCE is selected."

> ---
> 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.

Do you mean a table of all requirements in the draft?


> ---
> 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). 

Yes, the level of diversity provided may be higher than the requested one (e.g. you requested link diversity and the returned paths are node diverse), and this may be useful for the PCC to know the actual level. 
By the way the same applies to various path parameters (metric bound...).


>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?

No, there is only "required" diversity.

> ---
> Section 5.7
> There is a mention of AS-crossing. Is that in scope?

Strictly speaking no it isn't...but this is pretty linked.
Anyway we can remove it.

> ---
> Section 5.7
> How is the second bullet different from the first paragraph 
> of section 5.1?

No difference, can be removed.

> ---
> Do you need to add the ability to list areas that are to be 
> explicitly excluded form the path?

This is a good point, what about the following additional section:

"4.6. Area Exclusion

In some situations it may be useful to exclude one or more area(s) from the path (e.g. request for a path between LSRs in two stub areas connected to the same ABR(s), which must not cross the backbone area). Hence the request message MUST allow indicating a set of one or more area(s) that must be explicitely excluded from 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?

What about:

"The inter-area application implies some new manageability requirements in addition to those already listed in [RFC4657]. The PCECP PCC MIB module MUST allow recording the proportion of inter-area requests and the success rate of inter-area requests. It MUST also allow recording the performances of a PCE chain (minimum maximum and average response time), in case of multiple-PCE inter-area path computation.

A built in diagnostic tool MUST be defined to monitor the performances of a PCE chain, in case of multiple-PCE inter-area path computation. It MUST allow determining the minimum maximum and average response time globally for the chain, and on a per PCE basis."

> ---
> 
> 
> Nits
> ====

All these nits will be addressed.

Thanks again for this detailed review,

JL


> 
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/pce