Subject: [Pce] Comments on draft-vasseur-pce-brpc-00.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 10 Jun 2006 13:49:06 +0100

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?
==
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?
==
I'm assuming that section 1 is for short term information only and will be
deleted (in the next revision?)
==
Section 2. Terminology
s/ABR Router/ABR/
s/ASBR Router/ASBR/
Inter-area TE LSP: A TE LSP that crosses an IGP area.
    ...  s/IGP area/IGP area boundary/
LSR   ...please get this right!
==
Section 2
Boundary LSR
... the text seems to use 'boundary LSR', 'border node', 'boundary router'.
Can you find some consistency?
==
Section 2
I think draft-ietf-ccamp-inter-domain-framework would be a better reference
for definitions of stitching, contiguous and nesting
==
Section 3 para 3
s/proposes/defines/
==
Section 3
I think that the point about pd-path-comp is that it does not just provide a
mechanism for computing the paths, but it provides a mechanism for computing
and signaling the paths at the same time (although it could be adapted to be
just a computation technique, this is not what the pd-path-comp I-D is
describing). This is worth highlighting, because this draft is describing a
process for cooperation between PCEs in the absence of signaling (i.e. it is
truly a computation technique).
==
Section 3
   Although one model consists of making the boundary
   routers act as PCE,
I recommend removing this sentence. You could equally have said "although
one model consists of making every router with the lowest router ID in the
domain acting as a PCE". The sentence adds no value at this point in the
document since it is well-known that PCEs are just PCEs.
If a later example places the PCE function on the boundary routers then that
is where you should explain that it is only an example.
==
Section 3
   The mechanisms proposed in this document are also applicable
   to (G)MPLS TE domains other than areas and ASs.
s/proposed/defined/
I can smell an assertion! I suggest you add a section near the end of the
document to explain this statement, or remove it.
==
Section 4
Be careful to show that you mean MPLS TE, not simply TE.
==
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.
But also, what has the fact that the TE LSP spans multiple domains got to do
with preserving routing protocol scalability? Probably just delete from "in
the case..." to the end of the sentence.
==
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?
==
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!
==
Section 5
Some good work on clarifying things here since the previous version of the
I-D (sent to CCAMP). Thanks.
==
Section 5.1 and throughout
"BRPC path computation" seems to be tautologous
==
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.
==
Section 5.2
This is the second terminology section in the I-D, and there is some
duplication/overlap.
Jumping ahead of ourselves a bit, I can hear the IESG demanding that there
be only one terminology section per RFC.
==
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!
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.
Lastly, I suggest you make it clearer that, as the tree is relayed back
along the PCE sequence, the VSPT is pruned so that it only ever (assuming no
support of node-congruent diverse paths) contains one path from and
BR-en(i,j) to the destination.
==
Section 5.2
Please be careful with the use of "BR(s)" as it looks like the notation for
a BR of domain s!
You are allowed to use "BRs" in the sense of "one or more BR"
==
Section 5.2
   Note that PCE(i) would only consider BRs having connectivity with
   BR(s) of domain(i-1) in the VSPT(i).
I think this can be re-written as
   Note that PCE(i) only considers the entry BRs that provide
   connectivity from domain(i-1). That is, the set BR-en(j,i) is
   only those BRs that provide connectivity from domain (i-1) to
   domain(i).
==
Section 5.2
I found your step 1 and step 2 to be accurate but very hard to parse as
steps. can you break them down into atomic actions?
For example:
   Step 1
   a. The PCC selects a PCE(1) to serve its computation request
   b. The PCC sends the request to PCE(1)
   c. PCE(1) forwards the request to PCE(2), and each PCE(n)
      forwards the request to PCE(n+1). At each stage:
      i. PCE(n) determines the next domain or domains to be
         considered on the route. This may be achieved by
         static information configured at PCE(n) or by information
         encoded in the computation request, or through a combination
         of the two pieces of information through the application of
         policy.
      ii. PCE(n) determines PCE(n+1) through the knowledge of the
          next domain (domain(n+1)) and by configuration or discovery
          of the PCEs that compute paths for domain(n+1). Where more
          than one PCE is available for domain(n+1) PCE(n) makes the
          selection using local configuration, information carried on the
          path computation request, PCE capabilities, and policy.
      iii. If, at any stage, PCE(n+1) cannot be determined or reached,
           an error is returned to PCE(n-1) (see Section 7).

Do the same for Step 2 and the whole thing will be massively clearer.
==
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.
==
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
==
Section 6
I'm afraid that this is back on the process of providing reverse paths. Not
helpful in a TE environment where link properties may be unidirectional. The
requirements, therefore, is to supply paths from multiple entry points
towards a common destination (not the reverse).
==
Section 6
What is the VSPT object? It seems to be mentioned, but not defined.
Over time, I hope this section will be fleshed out to state exactly which
PCEP fields are used to carry what information on PCC-PCE(1) and
PCE(n)-PCE(n+1) requests, and PCE(1)-PCC, and PCE(n)-PCE(n-1) responses.
==
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.
==
Section 7
                         Error-value
                             1: BRPC procedure not supported by one or PCEs
                                along the domain path
I think you want to work on this text a bit. In fact, the problem is that no
PCE that supports the brpc procedure can be found for a domain in the list
of required domains along the path.
==
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?
==
Section 9
As well as needing to fold this into a more general applicability section, I
would suggest throwing out the marketing text (if you need to say why this
is good, put it in the intro as part of the problem to be solved) and
introducing some description of how to achieve the function. Does it allow
domain diversity? Does it allow shared border routers?
==
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.
==
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.
Maybe the PCE(n+1) should carefully monitor and limit (statistically and by
policy) brpc requests so that excessive information is not divulged?
==
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?
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-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Fri, 23 Jun 2006 10:11:53 -0400

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.

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

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

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

> reachability information (i.e. external routes) constitutes  

OK fine

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

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

> "BRPC path computation" seems to be tautologous

It is actually a double tautology ;-) (fixed).

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

> Frankly, we are building directional paths in exactly the oposite  

This is an abstract form of representation but see below,

> I suspect that this is just a textual descriptive issue rather than  

I clarified the text to avoid any ambiguity (VSPT defined as a MP2P  
tree).

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

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

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

> about what TE connectivity is available within an AS, and operating  

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.

> And, lastly, the text about re-optimisation belongs in the next  

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.

> metrics, etc. But these would compromise optimality.

Indeed.

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

> What are the implications on existing protocols (IGPs? PCEP?) of  

Absolutely ! I put a placeholder for a further revision.

Fully supportive of adding such section.

Many Thanks for your comments !

JP.

---

From: [email-masked]
Date: Sun, 25 Jun 2006 20:08:29 +0200

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.

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-masked]>
23/06/2006 16:11
 
        To:     "Adrian Farrel" <[email-masked]>
        cc:     [email-masked], [email-masked], 
[email-masked]
        Subject:        [Pce] Re: Comments on 
draft-vasseur-pce-brpc-00.txt

Hi,

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

==

==
Section 4

OK fine 

==
Section 4

It should actually read "pre-determined". Actually the best thing to do 
here is to remove "off-line"

==
Section 5

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

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!

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

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
configuration/advertisement/negotiation, or whether PCE(n+1) is supposed 
to

==
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
Maybe there are some things that can be done here based on policy, 
including

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?

JP.

etc.
==

==

---

From: JP Vasseur <[email-masked]>
Date: Sun, 25 Jun 2006 19:14:46 -0400

hi dimitiri,

On Jun 25, 2006, at 2:08 PM, [email-masked] wrote:

> computation of

Not correct; even if you know the sequence you still need the BRPC  
procedure to figure out the set of BN (boundary Nodes) to traverse to  
get the shortest inter-domain TE LSP: this is the whole issue with  
inter-domain, otherwise per-domain path computation would be sufficient.

> method such as to make the method not returning an error message

No, this is a constraint: "Give me the shortest path (potentially  
made of loose hops (the BNs)) that provides the shortest end to end  
path, considering that the additional constraint is to traverse the  
following set of domains <D1, D2, ....>.

> support the proposed method

BRPC is a multi-PCE based approach where you need at least one PCE  
per-domain.

> path through a domain not supporting this method -

heu ... yes indeed. If a domain does not support the method, the  
method cannot be used to compute the path.

> might be supportive of the method without supporting inter-AS link

No this is not a requirement, just an optimization. The only  
requirement is for the PCE to get the TE-related data about the Inter- 
AS links. I'll detail a bit more in the next revision.

> b3) at each step there is no PCE that has partial visibility of a  

This is not specific to BRPC. Even with intra-domain if you want to  
compute the path for a TE LSP, you cannot always use the PCE if it  
has a partial visibility. Note that this also applies to the case of  
co-located PCE (when the path is computed by the head-end).

> make the returned result void)

Again, this applies to other cases as well.

thanks.

JP.

> computation of
> node
> impact the
> ID,

---

From: [email-masked]
Date: Mon, 26 Jun 2006 01:35:16 +0200

hi j-p - see in-line

26/06/2006 01:14
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>, 
[email-masked], [email-masked], [email-masked]
        Subject:        Re: [Pce] Re: Comments on 
draft-vasseur-pce-brpc-00.txt

hi dimitiri,

[dp] inter-domain link selection (as i mentioned) implies what you mean 
with boundary nodes selection - you could rephrase by access/exit point 
selection exact same business

[dp] incorrect, this is not a "TE LSP" constraint - since so far when
a set of domains do not support/or support a given computation has not
yet become a constraint

[dp] indeed, but one PCE supporting that method and having FULL 
visibility of the domain

[dp] then you can never achieve - using your own words to make it more
straighforward - 

"you still need the BRPC procedure to figure out the set of BN (boundary 
Nodes) to traverse to get the shortest inter-domain TE LSP: this is the 
whole issue with inter-domain, otherwise per-domain path computation would 

be sufficient."

[dp] hence, to BRPC as well

[dp] ditto

thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Sun, 25 Jun 2006 20:42:00 -0400

hi dimitri,

> JP Vasseur <[email-masked]>

but again even if you know the sequence you still need BRPC to  
determine the set of BN (or exit point - same thing) that will give  
you the shortest inter-domain path. Look you wrote "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", which is not correct. Even if you know the sequence  
of domains, you still need the procedure to get the exit/entry point  
(named BN) that provide you the shortest inter-domain path.

> [dp] incorrect, this is not a "TE LSP" constraint -

Who said that this was a TE LSP constraint ? This is *a* constraint.  
If you impose the set of domain, this is a constraint.

Please read the text: "The BRPC procedure guarantees to compute the  
optimal path across a specific set of traversed domains (which  
constitutes an additional constraint)."

Note that at this point, I still do not see the point that you're  
trying to make here ?

> since so far when

So what is your point here ?

> [dp] then you can never achieve -

You can never achieve what ?

Sorry Dimitri, I'd love to accommodate your comment but I do not see  
your point ... hopefully we'll have a bit of time in Montreal to  
discuss if that does not work by email.

> using your own words to make it more
> straighforward -
>

Ah so we agree here :-)

What was your comment then ?

Thanks.

JP.

---

From: [email-masked]
Date: Mon, 26 Jun 2006 08:51:23 +0200

hi j-p - see in-line

26/06/2006 02:42
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], [email-masked], 
[email-masked]
        Subject:        Re: [Pce] Re: Comments on 
draft-vasseur-pce-brpc-00.txt

hi dimitri,

hi j-p - see in-line

hi dimitiri,

"==
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.

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

but again even if you know the sequence you still need BRPC to determine 
the set of BN (or exit point - same thing) that will give you the shortest 
inter-domain path. Look you wrote "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", which is not 
correct. Even if you know the sequence of domains, you still need the 
procedure to get the exit/entry point (named BN) that provide you the 
shortest inter-domain path.

Who said that this was a TE LSP constraint ? This is *a* constraint. If 
you impose the set of domain, this is a constraint.

Please read the text: "The BRPC procedure guarantees to compute the 
optimal path across a specific set of traversed domains (which constitutes 
an additional constraint)."

[dp] i read this, mind you, my point is that this is not a "constraint" of 
the same nature as the one you're making use such as minimize delays or 
whatsover - this constraint is introduced from the computation technique 
and mechanism of this proposed method 

Note that at this point, I still do not see the point that you're trying 
to make here ?

since so far when

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

a) this method provides a result iff all domains traversed by the 
request
support the proposed method

[dp] that the set of conditions to have this method workable is larger 
than the one listed in this doc.

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 -

Sorry Dimitri, I'd love to accommodate your comment but I do not see your 
point ... hopefully we'll have a bit of time in Montreal to discuss if 
that does not work by email.

[dp] my point is that without this additional information you can not 
achieve the expected result - i pointed to your own text to indicate that 
this information is a must have in order to achieve this objective 

"you still need the BRPC procedure to figure out the set of BN (boundary 
Nodes) to traverse to get the shortest inter-domain TE LSP: this is the 
whole issue with inter-domain, otherwise per-domain path computation 
would 

be sufficient."

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)

[dp] ditto

Ah so we agree here :-)

[dp] that you need to include these set of working conditions in the 
document itself, the document looks like quite simple in terms of 
conditions for having the proposed method working as expected while when 
you take a closer look at it this is not the case

Thanks.

JP.

thanks.

JP.

Hi,

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?)
==

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

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!

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.

==
Section 5.2
limit is not necessary. Also to explain 'flood' - flood to where, 
and how,

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

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

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

BRPC procedure per-say. As far as confidentiality is concerned, 
this only

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?

==
What are the implications of reporting multiple VSPT branches in 
PCEP to

JP.

etc.
==

==
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-masked]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Mon, 26 Jun 2006 08:54:47 -0400

hi,

ok so to summarize there was no technical feed-back just a few  
editorial comments.

You'd like to add to the following to the document:
1) The set of traversed domains has to be known and according to you  
this is not a constraint.
I think that the current text is quite clear:
"The BRPC procedure guarantees to compute the optimal path across a  
specific set of traversed domains (which constitutes an additional  
constraint)."
Now if you want to reword a bit to avoid using the word "constraint"  
although this *is* a constraint, this is no big deal.

Actually, interestingly enough there are quite a few cases where  
there's only one single set of traversed domains.

2) We need at least one PCE per domain
Sounds quite obvious but I have no problem adding this. Actually  
we're planning in the next revision to elaborate a little bit on the  
inter-As link flooding (again this is not a requirement but an  
optimization) but this will be covered.

JP.

On Jun 26, 2006, at 2:51 AM, [email-masked] wrote:

> determine

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 26 Jun 2006 14:14:05 +0100

Hi,

I'm trying to parse something out of this thread.

1. It is clear that brpc *demands* that the sequence of domains
    is already known before brpc is executed.
    In my opinion, this is clear in the I-D, but it would not hurt to
    make it clearer.
    A statement in the Abstract and Introduction would achieve
    this.

2. The mechanism by which the sequence of domains is known
    is out of scope for the procedure.
    It is not clear whether this is a limitation of the process, or
    not. But in my opinion this is consistent with the guidance
    that the WG received from the IAB when we were chartered.
    We are not trying to 'solve the Internet', so selection of
     domains is out of scope.

3. brpc *does* include mechanisms for the selection of interdomain
    links and/or nodes. This is more complex than the simple selection
    of these points of attachment because the connection to use may
    depend on the TE paths within the domains.
    IMO, brpc is constructed specifically for this purpose. If we did
    not need this function, we could use pd-path computation with
    visibility of the inter-domain TE links.

4. The discussion is not helped by debate about the precise wording
   around 'constraint'.
   Let us say that "the sequence of domains to be traversed is
   provided by an external source as a limiting factor to the computation
   or choice of paths."

Do we all agree with these statements?

Cheers,
Adrian

----- Original Message ----- 
From: <[email-masked]>
To: "JP Vasseur" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Monday, June 26, 2006 7:51 AM
Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt

---

From: JP Vasseur <[email-masked]>
Date: Mon, 26 Jun 2006 09:21:37 -0400

100%

Thanks,

JP.

On Jun 26, 2006, at 9:14 AM, Adrian Farrel wrote:

> ----- Original Message ----- From: <[email-masked]>

---

From: [email-masked]
Date: Mon, 26 Jun 2006 15:42:33 +0200

hi 

i don't think 1) and 2) have been captured 

on 1) there is a terminology issue - indeed - but there is also an issue 
that is the arbitrary selection/pruning of other potential alternatives - 
why that sequence ? and not another - was mentioned as the chicken-egg 
(technical) problem; first there may be many available interdomain paths 
that are never learned by the LSRs, more generically the diversity of the 
BGP routes available at each LSR is not sufficient to successfully provide 
for a satisfactory sequence; on the other hand, you may have receive 
multiple let's take an example to illustrate there are two AS path between 
A and D, one A-B-C-D the other A-E-F-D disjoint (on intermediate ASs) 
either both sequences are valid both policing and filtering makes you 
selecting the inappropriate sequence for the real TE-LSP consrttaints

on 2) this is part of the answer - the comment was PCE per domain 
supporting that method - and in case of two PCEs or more per domain i am 
not sure how one could guarantee that the proposed (recursive) sequence 
works (assumption is made that the PCE as full visibility on the whole 
domain but what in case of multiple PCEs per domain)

i have also asked to have a better description of the working conditions 
along this draft - to complete section 5.1 - 

if you consider this as non-technical or technical feedback that's your 
own appreciation 

thanks,
- dimitri.

26/06/2006 14:54

hi,

ok so to summarize there was no technical feed-back just a few editorial 
comments. 

1) The set of traversed domains has to be known and according to you this 
is not a constraint.

Actually, interestingly enough there are quite a few cases where there's 
only one single set of traversed domains.

2) We need at least one PCE per domain
Sounds quite obvious but I have no problem adding this. Actually we're 
planning in the next revision to elaborate a little bit on the inter-As 
link flooding (again this is not a requirement but an optimization) but 
this will be covered.

JP.

hi j-p - see in-line

hi dimitri,

hi j-p - see in-line

hi dimitiri,

"==
Section 5.1

but again even if you know the sequence you still need BRPC to determine 
the set of BN (or exit point - same thing) that will give you the 
shortest 
inter-domain path. Look you wrote "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", which is not 
correct. Even if you know the sequence of domains, you still need the 
procedure to get the exit/entry point (named BN) that provide you the 
shortest inter-domain path.

constitutes 

[dp] i read this, mind you, my point is that this is not a "constraint" 
of 
the same nature as the one you're making use such as minimize delays or 
whatsover - this constraint is introduced from the computation technique 
and mechanism of this proposed method 

since so far when

be sufficient."

[dp] ditto

Ah so we agree here :-)

Thanks.

JP.

thanks.

JP.

Hi,

Thanks,
Adrian

==

==

==
Section 4

OK fine

==
Section 4

==
Section 5

==

==
Section 5.1

==
Section 5.2

==
Section 5.2

==
Section 5.2

==
Section 7

==
Section 8

Section 10

==
Section 13

Indeed.

==

JP.

etc.
==

==

---

From: [email-masked]
Date: Mon, 26 Jun 2006 16:13:08 +0200

adrian - 

ok (nice summary) - i think the whole debate is on point 2) since last 
meeting discussions - if one agrees that we don't solve this issue - then 
being aware upfront/descriptive of limitations, conditions and workability 
is really appropriated - let's assume this is (hopefully) the case

the more important implication is point 3) - if this inter-domain link is 
not provided - de facto - as part of the method what does this method 
really provides ? i mean section 7. reads as if you can not flood just 
makes PCE aware of that TE data; however, point on whether this info is 
flooded or passed to the PCE or not the main issue is how this information 
is locally obtained ? what does happen if this information is only 
partially or not known, changing conditions, a unidirectional LSP reserves 
bandwidth downstream how accounting occurs (edges need to be aware of 
forward and reverse bandwidth), etc.

thanks,
- dimitri.

"Adrian Farrel" <[email-masked]>
26/06/2006 15:14
Please respond to "Adrian Farrel"
 
        cc:     <[email-masked]>

Hi,

Cheers,
Adrian

----- Original Message ----- 
From: <[email-masked]>
To: "JP Vasseur" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>

shortest
sequence
constitutes
of
> Sorry Dimitri, I'd love to accommodate your comment but I do not see 
your

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 26 Jun 2006 16:01:03 +0100

Thanks Dimitri,

This is converging nicely.

> is really appropriated - let's assume this is (hopefully) the case

Then that is an action for the authors to make points 1 and 2 *very* clear 
in the I-D (at the top!)

> forward and reverse bandwidth), etc.

I suspect you do not mean section 7?

So, if I may rephrase....
You are concerned about how the brpc process would operate if there is an 
inter-domain link (e.g. inter-AS) and the TE information for this link is 
not fully known.

Let's quickly look at who needs to know.

The downstream PCE provides paths from entry points to its domain (BR-en(i)) 
to the destination. So the downstream PCE is not interested in the TE links 
entering the domain.

The upstream PCE provides paths from the entry points to its domain 
(BR-en(i-1)) to the destination. It computes these by computing 'optimal' 
paths from each BR-en(i-1) to the destination [says the I-D in step 2]. But 
this is highly unclear!

Obviously, PCE(i-1) can compute the paths from each BR-en(i-1) to each 
BR-ex(i-1), but in order to build the tree we need the paths to be computed 
from each BR-en(i-1) to each BR-en(i). These paths include the inter-domain 
TE links (where they exist).

So....

Either there is an assumption that this TE link information is available, or 
there is a step missing in the process.

Perhaps the authors could clarify here and in the I-D.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 26 Jun 2006 16:19:59 +0100

>> Appendix A,

You could always tell the tools team about this.

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

Good.

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

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

>> ==
>> 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.
>> 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:

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?

>> ===
>> "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
>> available this is obvious; in the case of a network failure, *any*
>> path is better than no path!)
>> section, not in this section.
>>
>

OK. Yes, some wordsmitthing is needed to explain local optimisation (for 
stitching *and* tunneling) compared to end-to-end optimisation.

Cheers,
Adrian

---

From: JP Vasseur <[email-masked]>
Date: Thu, 29 Jun 2006 10:09:58 -0400

Hi Adrian,

Let me do this:
1) Reply to several emails individually
2) Send a summary to the list to make sure that all comments have  
been captured and will be addressed in the next revision.

See below,

On Jun 26, 2006, at 11:01 AM, Adrian Farrel wrote:

> Then that is an action for the authors to make points 1 and 2  
> *very* clear in the I-D (at the top!)

No problem to move some statement at the top ;-) Will do.

Here is the proposed new abstract:

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 along a determined sequence of domains, using a backward
    recursive path computation technique while preserving  
confidentiality
    across domains, which is sometimes required when domains are
    managed by different Service Providers.

> You are concerned about how the brpc process would operate if there  
> is an inter-domain link (e.g. inter-AS) and the TE information for  
> this link is not fully known.
>
> The downstream PCE provides paths from entry points to its domain  
> (BR-en(i)) to the destination. So the downstream PCE is not  
> interested in the TE links entering the domain.
>
> (BR-en(i-1)) to the destination. It computes these by computing  
> 'optimal' paths from each BR-en(i-1) to the destination [says the I- 
> D in step 2]. But this is highly unclear!
>
> Obviously, PCE(i-1) can compute the paths from each BR-en(i-1) to  
> each BR-ex(i-1), but in order to build the tree we need the paths  
> to be computed from each BR-en(i-1) to each BR-en(i). These paths  
> include the inter-domain TE links (where they exist).

This is actually not needed - see below

>
> So....
>
> Either there is an assumption that this TE link information is  
> available, or there is a step missing in the process.
>

OK let's clarify then.

The text in the draft says:

  Step i:

    - For i=n-1 to 2:

    PCE(i) concatenates the ASi topology (using its TED) with the
    received VSPT(i+1) and computes VSPT(i).

And this is where we could elaborate if you will. What PCE(i) has to  
do is to concatenate the received VSPT from PCE(i+1) to its ASi  
topology (by the way, there's a typo there, it should read "domain"  
rather than "AS") including the inter-AS TE links (in the case of  
Inter-AS). Once such operation is performed, it is quite easy to  
compute the new VSPT (MP2P tree) from each BN(j,i) and return it to  
the upstream PCE.

So I propose to rephrase as follows:

Step i:

    - For i=n-1 to 2:

    PCE(i) concatenates the topology of domain (i) (using its TED)
    with the received VSPT(i+1). In the case of Inter-AS TE LSP
    computation, this requires to also add the inter-AS TE links
    connecting the domain (i) to the domain (i+1).
    Then PCE(i) computes VSPT(i) (P2MP tree made of the shortest
    constrained paths between each BN-en(j,i) and the TE LSP  
destination).

Does that clarify ?

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 29 Jun 2006 10:16:30 -0400

Hi Adrian,

> You could always tell the tools team about this.

We discussed it some time ago - will re-activate the discussion.

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

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

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