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