the following comment was also discussed during last meeting
"==
Section 5.1
I like the simplicity of section 5.1, but I think you need to point out
that
if the sequence of domains is known a priori (can you determine it a
priori?) then the path computed might not be 'optimal' in the usual sense
of
the word, but that this is OK because the ordered list of domains
constitutes an additional constraint on the computation so the resultant
path *is* optimal within the constraints applied.
Can't agree more. Good suggestion, thanks.
Updated text: "The PCE-based BRPC procedure applies to the computation of
an optimal constrained inter-domain TE LSP. The sequence of domains to be
traversed can either be determined a priori or during the path computation
procedure. The BRPC procedure guarantees to compute the optimal path
across a specific set of traversed domains (which constitutes
an additional constraint). In the case of an arbitrary set of meshed
domains, the BRPC procedure can be used to compute the optimal path across
each domain set in order to get to optimal constrained path between the
source and the destination of the TE LSP."
=> in brief, how to determine the sequence through which path computation
has to be performed because if this sequence was known there is no need
for such procedure (only inter-domain link selection would be required) -
now adrian mentions that pre- determination becomes a new constraint -
well actually this is not a constraint for the TE LSP itself but a
restriction on the domain set known to be (a-priori) supportive of the
method such as to make the method not returning an error message
hence sentence "The BRPC procedure guarantees to compute the optimal path
across a specific set of traversed domains (which constitutes
an additional constraint). In the case of an arbitrary set of meshed
domains, the BRPC procedure can be used to compute the optimal path across
each domain set in order to get to optimal constrained path between the
source and the destination of the TE LSP."
should as far as i understand the method fulfill the following
a) this method provides a result iff all domains traversed by the request
support the proposed method
b) this method provides an "optimal" result iff
b1) all possible sequences of domains have been traversed (starting from
the root) and are supportive of that method - as there might be an optimal
path through a domain not supporting this method -
b2) there is no discontinuity in the availability of the inter-AS link
information on each PCE performing a given selection - indeed a domain
might be supportive of the method without supporting inter-AS link
flooding
b3) at each step there is no PCE that has partial visibility of a given
domain
b4) during the selection process no network conditions changes (that would
make the returned result void)
JP Vasseur <[EMAIL PROTECTED]>
23/06/2006 16:11
To: "Adrian Farrel" <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: [Pce] Re: Comments on
draft-vasseur-pce-brpc-00.txt
Many Thanks Adrian for the comments.
We incorporated the vast majority of them in the new revision (just
posted).
See below for the comments requesting some clarification.
On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote:
Hi,
Thanks for keeping these ideas alive.
Here are some picky thoughts that you may want to include in the next
revision to make it more robust as a document. I don't have any issues
with
the basic process.
Thanks,
Adrian
==
Is this I-D likely to be Informational or Standards Track? From Appendix
A,
this looks like Standards Track. Can you remove Appendix A and put the
status in the usual place in the header?
==
Status has been updated (Informational) but let's discuss this later on.
FYI, it does not appear on the front page when using the xml2rfc editor
(which by the way is excellent), thus the appendix addition.
It would be nice if the Abstract contained a pithy summary of brpc and/or
gave the motivation for the draft. For example, what is the method trying
to
achieve that isn't achievable by other methods? Or, what is the
fundamental
element of brpc that is not in other methods?
Agree. Here is the new Abstract:
"The ability to compute constrained shortest Traffic Engineering (TE)
Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks across multiple domains (where 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) has been identified as a key requirement .
This document specifies a procedure relying on the use of multiple Path
Computation Elements (PCEs) in order to compute such inter-domain shortest
constraint paths, using a backward recursive path computation technique
while fully preserving confidentiality requirements across domains. "
==
I'm assuming that section 1 is for short term information only and will be
deleted (in the next revision?)
==
Indeed, just to provide a bit of history for the ones who have been
following inter-domain path computation for a while.
==
Section 4
- 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.
You should clarify what you are saying here, because many would argue that
reachability information (i.e. external routes) constitutes topology and
resource information.
OK fine
==
Section 4
- 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.
Why does the policy agreement need to be offline?
It should actually read "pre-determined". Actually the best thing to do
here is to remove "off-line"
==
Section 5
No assumption is made on the actual path computation algorithm in use
by the PCE (it can be any variant of CSPF, algorithm based on linear-
programming to solve multi-constraints optimization problems and so
on).
Suggest that you delete the text in parenthesis because it is making
suggestions that border on assumptions!
Well I'd suggest to keep it as is since the point is to differentiate the
path computation procedure from the algorithm to compute each intra-domain
path segment. Furthermore, we'd like to highlight the fact that the BRPC
procedure does not mandate for each PCE to use CSPF, could be other
algorithm.
==
Section 5.1 and throughout
"BRPC path computation" seems to be tautologous
It is actually a double tautology ;-) (fixed).
==
Section 5.1
I like the simplicity of section 5.1, but I think you need to point out
that
if the sequence of domains is known a priori (can you determine it a
priori?) then the path computed might not be 'optimal' in the usual sense
of
the word, but that this is OK because the ordered list of domains
constitutes an additional constraint on the computation so the resultant
path *is* optimal within the constraints applied.
Can't agree more. Good suggestion, thanks.
Updated text: "The PCE-based BRPC procedure applies to the computation of
an optimal constrained inter-domain TE LSP. The sequence of domains to be
traversed can either be determined a priori or during the path computation
procedure. The BRPC procedure guarantees to compute the optimal path
across a specific set of traversed domains (which constitutes
an additional constraint). In the case of an arbitrary set of meshed
domains, the BRPC procedure can be used to compute the optimal path across
each domain set in order to get to optimal constrained path between the
source and the destination of the TE LSP."
==
Section 5.2
The introduction of the term Virtual Shortest Path Tree is hard to parse
and
to my mind the definition is arse about tit. I think you could usefully
add
some textual definition of what the VSPT is trying to achieve, before
presenting it in pictorial or abstract form.
Even more important (I think) is the fact that the tree as presented
"represents the shortest path between the destination and BR-en(j,i)..."
Frankly, we are building directional paths in exactly the oposite
direction!
This is an abstract form of representation but see below,
So the VSPT is still a tree, but it is an MP2P tree, not a P2MP tree as
described.
I suspect that this is just a textual descriptive issue rather than
anything
broken in the process.
I clarified the text to avoid any ambiguity (VSPT defined as a MP2P tree).
==
Section 5.2
I suggest that you pull the note (Note: in term of computation...) out
into
a separate section. It doesn't belong in the middle of section 5.2.
You will probably want to re-write the text as well since the
unidirectional
limit is not necessary. Also to explain 'flood' - flood to where, and how,
and by whom? And you will want to add to pieces of information:
- the link to the I-D that defines how to do this
- a description of what happens if this process is not used.
This only works for unidirectional LSPs: indeed, the exit boundary node
can flood TE-related data in its LSA/LSP for the link
exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP running on
the link but how would a node in domain (i) get the TE-related data for
the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on
unidirectional link. Are we in sync ?
==
Section 5.2
The paragraph that begins "BRPC guarantees to find the optimal..." is a
nascent Applicability Statement. I suggest moving this to another Section
and significantly beefing it up. You need to describe more fully:
- how ECMP works (the PCC has to request the return of more than one path)
- how diversity works (i.e. section 9 fits in here)
- how some freedom of selection of domains can be offered
- how to mix the method with other mechanisms
This was (and is) planned for future revision. Note that ECMP and
diversity are discussed already but we're planning the flesh out these
sections in further revision.
==
Section 7
If the BRPC procedure cannot be completed because a PCE along the
domain path does not support the procedure, a PCErr message is
returned by the upstream PCE with a Error-Type "BRPC procedure
completion failure". The PCErr message MUST be relayed to the
requesting PCC.
Not clear to me whether PCE(n) is supposed to know that PCE(n+1) does not
support brpc, presumably through capabilities
configuration/advertisement/negotiation, or whether PCE(n+1) is supposed
to
respond to the path computation request saying that it does not support
bit-V of the RP object. If the latter, presumably the PCErr comes from
PCE(n+1) and not from PCE(n) as documented.
Good catch, typo: it should read "a PCErr message is returned to the
upstream".
The plan is to define a capability bit (IGP) in a further revision.
==
Section 8
Metric normalisation is a great potential solution, but how does it fit
with
AS topology confidentiality? What is the solution to providing discretion
about what TE connectivity is available within an AS, and operating brpc?
Metric normalization is handled locally by the PCE and does not impact the
BRPC procedure per-say. As far as confidentiality is concerned, this only
requires for the SPs to exchange metric mapping information (nothing
related to the network topology or resources); for example
SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1
SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10
A simple metric normalization can then be performed on the PCE thanks to
simple cost mapping tables.
Section 10
Some of this text has been seen before in this I-D
Why do you single out LSP stitching as possibly breaking end-to-end
optimality. There is functionally no difference between stitching and
nesting in this respect.
But further, your statement about stitching is pejorative! If you say that
"In the case where a domain has more than one BR-en or more than one
BR-ex,
optimality after some network change within the domain can only be
guaranteed by re-executing the full brpc computation" then I would agree
with you. But as phrased, it implies that making a per-domain
re-optimisation could make the path *less* optimal. This (of course) is
not
the case - per-domain optimisation will always improve or leave the same
end-to-end optimality (in the case where new resources are made available
this is obvious; in the case of a network failure, *any* path is better
than
no path!)
And, lastly, the text about re-optimisation belongs in the next section,
not
in this section.
Yes I wanted to leave that text to keep track of who would read the ID,
expecting reaction ;-)) Per-domain reoptimization would always improve the
current path *but* in case of stitched LSPs, TE LSP segments are computed
by the stitching point; thus in case of failure, they could end up
following a non optimal path whereas in the case of contiguous LSP, the
BRPC procedure would be called again thus leading to the optimal path
again. The point that I was trying to make is "if you have a stitched LSP
and rely on BRPC when first signaled in an attempt to get an optimal path,
you need to consider the interaction between the local reopt mode and BRPC
if the goal is to preserve an optimal path at any given time". Anyway,
we're on the same page and I agree and the text should be reworded
according to your proposal to avoid any misunderstanding.
==
Section 13
I would like you to discuss the issues of confidentiality of topology
information at greater length. It seems that you would possibly use this
technique in conjunction with path cookies, which is fine. But, are there
two things you cannot escape from?
- indicating which BR-en provides best connectivity
- indicating the metric for multiple BR-ens
Maybe there are some things that can be done here based on policy,
including
not reporting all of the BR-ens, ranking rather than giving absolute
metrics, etc. But these would compromise optimality.
Indeed.
Maybe the PCE(n+1) should carefully monitor and limit (statistically and
by
policy) brpc requests so that excessive information is not divulged?
Since one of objectives for using the BRPC procedure is to compute an
optimal path, we need to know at least the BN (Boundary Nodes) and the
cost.
==
I wouldn't mind seeing a Management Considerations section.
Do we need to be able to examine the pruned pieces of VSPT at transit
PCEs?
What are the implications of reporting multiple VSPT branches in PCEP to
the
MIB modules?
Is brpc support something that needs to be configured: per PCE?; per
PCE-neighbor?
What are the implications on existing protocols (IGPs? PCEP?) of using
brpc?
Absolutely ! I put a placeholder for a further revision.
Fully supportive of adding such section.
Many Thanks for your comments !
JP.
etc.
==
I think Jean-Louis' email address needs updating
==
The document would benefit from a little care in the formatting, and you
could usefully re-read it for missing words, etc.
==
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
