Hi Adrian,
On Jun 26, 2006, at 11:19 AM, Adrian Farrel wrote:
==
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.
You could always tell the tools team about this.
We discussed it some time ago - will re-activate the discussion.
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. "
Good.
==
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.
Honetsly, I think that everything you want to say is covered by "No
assumption is made on the actual path computation algorithm in use
by the PCE"
The text in parentheses is overly suggestive, and not as generic as
you might hope.
If you need/want to convey a more detailed message, I suggest you
do it by explicit text, not by example. Add in place of the
parentheses...
"That is, the path computation procedure is separated from the
computation algorithm and the algorithm need not be limited to
simple CSPF."
Like it, thanks.
==
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 ?
Ah. This seems to be Dimitri's point.
Does that mean that brpc cannot be applied to bidirectional
services where inter-domain links exist? Is that consistent with
the use for GMPLS?
We'd need to slightly adjust the procedure. Will add a section on
this in a further revision of the document.
===
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.
OK. Yes, some wordsmitthing is needed to explain local optimisation
(for stitching *and* tunneling) compared to end-to-end optimisation.
OK, thanks for the comments.
Cheers,
JP.
Cheers,
Adrian
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
