------ Forwarded Message > From: JP Vasseur <[EMAIL PROTECTED]> > Date: Sat, 29 Mar 2008 15:15:37 -0400 > To: <[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/pce
