----- Original Message -----
Sent: Tuesday, May 09, 2006 9:54 AM
Subject: Re: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt
Hi Dean,
Many thanks for your comments. Replies/Discussion in line,
- No topology or resource information is distributed between domains
(as mandated per [RFC4105] and [RFC4216]), which is critical to
preserve IGP/BGP scalability and confidentiality in the case of TE
LSPs spanning multiple domains.
DC2 - This is practically true but if not, the BRPC procedure can
still be used.
JP>> Yes, but we want to clarify the fact BRPC does not require any topology or resource information distribution across domains. We'll reword to clarify.
- While certain constraints like bandwidth can be used across
different domains, certain other TE constraints like resource
affinity, color, metric, etc. as listed in [RFC2702] could be
translated at domain boundaries. If required, it is assumed that, at
the domain boundary LSRs, there will exist some sort of local mapping
based on offline policy agreement, in order to translate such
constraints across domain boundaries during the inter-PCE
communication process.
DC3 - This may also be relaxed as an assumption. These constraints
may be globally or locally (thus may need mapping) defined,
but in either case, the BRPC procedure may be applied.
JP>> Well at least not for the cost metric that must be consistent to compute the shortest inter-domain constrained path. You're right that other metrics apply to the general inter-domain case and are not specific to BRPC.
- Each AS can be made of several IGP areas. The path computation
procedure described in this document applies to the case of a single
AS made of multiple IGP areas, multiples ASs made of a single IGP
area or any combination of the above. For the sake of simplicity,
each AS will be considered to be comprised of a single area in this
document. The case of an Inter-AS TE LSP spanning multiple ASs where
some of those ASs are themselves made of multiple IGP areas can be
easily derived from this case by applying the BRPC procedure
described in this document, recursively.
DC4 - The BRPC procedure in general can be applied to any network
partitions in the context of (G-)MPLS networks, and so this
paragraph could be moved to the Intruduction, and at least
not a hard assumption.
JP>> Agree.
- The domain path (set of domains traversed to reach the destination
domain) is either administratively pre-determined or discovered by
some means (outside of the scope of this document).
DC5 - What does this mean ? Thought the domain path is calculated by
the BRPC procedure.
JP>> nope, the BRPC computes the optimal (shortest) path between a source S in Domain A to destination D in Domain B, along a determined domain path (can be pre-determined or discovered during the BRPC procedure). But, BRPC does not attempt to discover all the domain-path, compute for each domain path the best path and return the absolute best path.
DC10 Thr BRPC procedure may return x number of path segments where x equals
the number of equal cost paths (ECMP), where two parameters may be
configurable based on carriers policy. The first is the max number for
x, and the second is the approximates of these paths (costs are
exactly the same or close enough).
JP> Do you see a strong reason for limiting x ?
The second requirement might indeed be interesting.
WG, any feed-back on this ?
DC11 - It could be reworded to say: After accommodating local policy
that may be associated with domains that a LSP may traverse,
if any, the BRPC would guarantee the optimality of inter-domain
paths end-to-end.
JP> Not quite sure to see your point here ?
Thanks for your comments.
JP.
On May 8, 2006, at 5:57 PM, Dean Cheng ((dcheng)) wrote:
Dear Authors,
I've got some quick feedback please see the attached (lines inserted
starting with DC).
Cheers,
Dean
Dear WG,
As agreed during our last WG meeting in Dallas (see the discussion with Adrian, acting as CCAMP co-chair), we moved that ID in PCE WG. We took that opportunity to make several changes based on the comments that we received so far. So new text has been added for clarification, we reworded some sections and more importantly, we removed the specification of the VSPT object and replaced it by a 1-bit new flag in the RP object defined in PCEP.
Comments very welcome.
JP, Raymond, Nabil and Jean-Louis.Begin forwarded message:
Date: May 4, 2006 3:50:01 PM EDT
Subject: I-D ACTION:draft-vasseur-pce-brpc-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : A Backward Recursive PCE-based Computation
(BRPC) procedure to compute shortest inter-
domain Traffic Engineering Label Switched Paths
Author(s) : J. Vasseur, et al.
Filename : draft-vasseur-pce-brpc-00.txt
Pages : 14
Date : 2006-5-4
This document specifies a Path Computation Element (PCE)-based
procedure to compute inter-domain constrained shortest Traffic
Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks. In this
document a domain is referred to as a collection of network elements
within a common sphere of address management or path computational
responsibility such as IGP areas and Autonomous Systems.
A URL for this Internet-Draft is:
To remove yourself from the I-D Announcement list, send a message to
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-vasseur-pce-brpc-00.txt".
A list of Internet-Drafts directories can be found in
Internet-Drafts can also be obtained by e-mail.
Send a message to:
In the body type:
"FILE /internet-drafts/draft-vasseur-pce-brpc-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
_______________________________________________
I-D-Announce mailing list
<draft-vasseur-pce-brpc-00DC.txt>
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
