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

Thu, 29 Jun 2006 07:10:23 -0700 

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:


Thanks Dimitri,

This is converging nicely.


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



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.




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.


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


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.


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


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.



Thanks,
Adrian







"Adrian Farrel" <[EMAIL PROTECTED]>
26/06/2006 15:14
Please respond to "Adrian Farrel"

       To:     Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED]
       cc:     <[EMAIL PROTECTED]>
       Subject:        Re: [Pce] Re: Comments on
draft-vasseur-pce-brpc-00.txt


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 PROTECTED]>
To: "JP Vasseur" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, June 26, 2006 7:51 AM
Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt



hi j-p - see in-line




JP Vasseur <[EMAIL PROTECTED]>
26/06/2006 02:42

       To:     Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED]
       cc:     [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
       Subject:        Re: [Pce] Re: Comments on
draft-vasseur-pce-brpc-00.txt


hi dimitri,

On Jun 25, 2006, at 7:35 PM, [EMAIL PROTECTED] wrote:

hi j-p - see in-line




JP Vasseur <[EMAIL PROTECTED]>
26/06/2006 01:14

       To:     Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED]
       cc:     "Adrian Farrel" <[EMAIL PROTECTED]>,

[EMAIL PROTECTED], [EMAIL PROTECTED],  
[EMAIL PROTECTED]

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


hi dimitiri,

On Jun 25, 2006, at 2:08 PM, [EMAIL PROTECTED] wrote:

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

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.



[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


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.



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


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

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


[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

a set of domains do not support/or support a given computation  
has not

yet become a constraint

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

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

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

So what is your point here ?


[dp] that the set of conditions to have this method workable is  
larger

than the one listed in this doc.

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 -


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


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

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.

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


[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

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

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


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

[dp] hence, to BRPC as well

b4) during the selection process no network conditions changes
(that would
make the returned result void)


Again, this applies to other cases as well.

[dp] ditto


Ah so we agree here :-)

What was your comment then ?

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






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



_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce














_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce


_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce






















					Reply via email to