[Pce] FW: LC comments on draft-ietf-pce-interas-pcecp-reqs-04.txt

[JP Vasseur <jvasseur at cisco.com>]

------ Forwarded Message
> From: JP Vasseur <jvasseur at cisco.com>
> Date: Sat, 29 Mar 2008 15:15:37 -0400
> To: <pce at ietf.org>
> Conversation: LC comments on draft-ietf-pce-interas-pcecp-reqs-04.txt
> Subject: LC comments on draft-ietf-pce-interas-pcecp-reqs-04.txt
> 
> Hi,
> 
> Here are some last call comments on draft-ietf-pce-brpc-07.txt
> 

Of course it should read Here are some last call comments on
draft-ietf-pce-interas-pcecp-reqs-04.txt

>   Checking references for intended status: Informational
>   ----------------------------------------------------------------------------
> 
> == Outdated reference: draft-ietf-ccamp-inter-domain-rsvp-te has been
>    published as RFC 5151
> 
> == Outdated reference: draft-ietf-ccamp-lsp-stitching has been published as
>    RFC 5150
> 
> == Outdated reference: draft-ietf-ccamp-inter-domain-pd-path-comp has been
>    published as RFC 5152
> 
> Other comments
> ##############
> 
> * First page: All authors are editors so you can remove "Editors" after the
> names.
> 
> * Please make sure that the title and all section headings use capitals
> 
> * Just to be consistent with several other documents: s/ MPLS-TE/ MPLS TE
> 
> * s/definition/Terminology for the title of section 2.
> 
> * There are several places in the document where it would be preferable to
> replace "path" by "constrained path". Ex:
> " The mechanisms in [INTERD-TE-PDPC]
> do not guarantee an optimum path across multiple ASes where an
> optimum path for an LSP is one that has the smallest cost"
> 
> *  s/ TE-constraints/TE constraints.
> 
> * You may want to use a consistent terminology throughout the document:
> "inter-AS route", "inter-AS path", "inter-AS TE LSP".
> 
> * In the introduction please expand acronyms when first used: LSPs, (G)MPLS.
> 
> * Section 3
> 
> - s/ "R1 in AS1 wants to setup a MPLS-TE or a GMPLS path"/ "R1 in AS1 wants
>    to setup (G)MPLS TE LSP"
> - s/ "R1, as a PCC, sends a PCECP path request to PCE1"/ "R1, as a
>    PCC, sends a PCECP path computation request to PCE1".
> - s/ " PCE1 sends a PCECP path request to PCE2"/" PCE1 sends a PCECP path
> computation request to PCE2"
> - You wrote:  " R4 returns a PCECP path response to PCE2 with ASBR3 as
>     the entry point to AS2 from AS1 and ASBR7 as the exit point to AS3.
>    PCE2 then sends a PCECP path request to PCE3 to compute the path
>    segment across AS3, starting at ASBR7 and terminating at R7."
> 
> You may want to indicate that the choice of ASBR7 is taken for the sake of
> illustration.
> 
> 
> * Section 4:
> 
> - " This section discusses detailed PCECP requirements for inter-AS
>    MPLS-TE and GMPLS LSPs."
> May be a bit confusion ... How about " This section discusses detailed PCECP
> requirements for inter-AS (G)MPLS TE"
> 
> - " Specifically, some requirements are more applicable to inter-
>    provider inter-AS MPLS-TE and GMPLS operations than to intra-
>    provider operations. "
> 
> Is a bit ambiguous. How about:
> 
>  " Specifically, some requirements are more applicable to inter-
>    provider inter-AS than to intra-provider inter-AS MPLS TE and GMPLS
> operations. "
> 
> - " 1. [RFC4657] states the requirement for a priority level to be
>    associated with each path computation request. This document does
>    not change that requirement, but, in addition, it MUST be possible
>    for an inter-AS PCE to apply local policy to vary the priority of
>    path computation requests received across AS borders."
> 
> Since the policy is local, why is this a requirement for the PCECP?
> 
> - "4. A PCECP path request from one inter-AS PCE to another MUST
>    include the previous AS number in the path of the LSP to enable the
>    correct application of local policy at the second inter-AS PCE. "
> 
> Don't you mean ? :
> 
> "4. The PCECP MUST provide the ability to include the previous AS number in
> the path of the LSP in a path computation request from one inter-AS PCE to
> another. That to enable the correct application of local policy at the second
> inter-AS PCE. "
> 
> - "6. PCECP MUST support the disjoint path requirements specified in
>    [RFC4657] and MUST further allow the specification of AS-diversity
>    for the computation of a set of two or more paths. "
> 
> The first MUST should be removed here since it is specified in RFC4657. It
> should read:
> 
> "6. As specified in [RFC4657], PCECP must support the disjoint path
> requirements. In addition to this requirement, PCECP MUST further allow the
> specification of AS-diversity for the computation of a set of two or more
> paths. "
> 
> Section 4.1.2
> 
> - " 6. A PCECP path computation response MUST be able to identify
> diversified paths for the same (G)MPLS-TE LSP."
> 
> What did you mean by "same" here?
> 
> Section 4.3
> 
> - " The PCECP MIB module MUST provide objects to control the behavior of
>    PCECP in inter-AS applications.  They include the ASes within the
>    scope of an inter-AS PCE, Inter-AS PCEs in neighboring ASes to which
>    the requesting PCE will or will not communicate, confidentiality and
>    policies, etc.. "
> 
> Since you enumerate "objects", it is a bit awkward to terminate the sentence
> by "etc ..." You may want to either provide the exhaustive list or remove the
> "etc".
> 
> Section 4.4
> 
> - S/" Confidentiality rules may also apply among ASes under a single
> Provider"/" Confidentiality rules may also apply among ASes under a single
> SP"
> 
> - Just a terminology issue:
> 
> " Each SP will in most cases designate some PCEs for inter-AS
> MPLS-TE or GMPLS path computation within its own administrative domain
> and some other PCEs for inter-provider inter-AS MPLS-TE or GMPLS path
> computation."
> 
> In several places you use the term "inter-AS MPLS-TE or GMPLS path
> computation". You may want to replace it by "inter-AS (G)MPLS TE path
> computation".
> 
> - s/" PCECP SHOULD allow an SP to hide from other SPs the set of hops
>    within its own ASes that are traversed by an inter-AS inter-provider
>    LSP (c.f., Section 5.2.1 of [RFC4216])."/" PCECP SHOULD allow an SP to hide
> from other SPs the set of hops within its own ASes that are traversed by an
> inter-AS inter-provider TE LSP (c.f., Section 5.2.1 of [RFC4216])."
>                              ^^^^
> Please make sure to consistently use "TE LSP": you are using LSP, TE LSP, ...
> 
> - In section 4.1.2:
> 
> " 2. A PCECP path computation response from one inter-AS PCE to the
> requesting inter-AS PCE MUST be able to carry an identifier for a path
> segment it computes to preserve path segment and topology
> confidentiality. The objective of the identifier is to be included in
> the LSP signaling, whose mechanism is out of scope of this document, to
> be used for path expansion during LSP signaling."
> 
> Then in section 4.4, you write:
> 
> " PCECP SHOULD allow an SP to hide from other SPs the set of hops
>    within its own ASes that are traversed by an inter-AS inter-provider
>    LSP (c.f., Section 5.2.1 of [RFC4216]). "
> 
> And in section 5.3:
> 
> "5.3. Confidentiality
>  
> The PCECP SHOULD also provide mechanism to preserve the confidentiality
> of path segments computed by a PCE in one AS and provided to a
> computation response in another AS. "
> 
> 
> Should the SHOULD be MUST here to be consistent?
> 
> Section 5.3
> 
> - "Not only is it necessary for such
> mechanisms to be provided in PCECP responses, but signaling messages
> MUST also provide mechanisms such that an ASBR receiving an incoming
> signaling request can apply policy to reject signaling messages that do
> not contain the computation responses produced by the local PCE."
> 
> The issue is that the MUST applies to signaling ... This document is about
> PCECP.
> 
> Thanks.
> 
> JP.

------ End of Forwarded Message

_______________________________________________
Pce mailing list
Pce at ietf.org
https://www.ietf.org/mailman/listinfo/pce