Subject: comments on ARO

From: [email-masked]
Date: Mon, 19 Apr 2004 21:08:05 +0200

Hi Vishal,

looking to draft-dachille, I have following comments:

1) Second paragraph in section 2 is not clear: "we will assume that
every
inter-area connection is duplicated". I understood from it that when
the
primary path follows Area1-Area2-Area3, then also the secondary has
to
follow this path but using other border nodes. But then from section
4.2 I
understand that this is not an assumption?

2) step 2c on page 5: also E, G and H has to be pruned? It is also
not
clear which path is selected in area 3: I guess it is E-G-H for
primary and
F-H for secondary?

3) (!) page 7, about the trap-avoid reference: If fact it is just a
matter
of doing a good path calculation. If the primary is signaled and
border
nodes know that also a secondary has to be established, then it can
make
sure that the primary does not introduce such a trap. This assumes
that the
border node also has to know that a secondary has to be established.
This
is known by the presence of the ARO object but this does not mean
that at
the end, the ARO has to contain a full strict path of the secondary.
Border
nodes can expand the ARO by only including the border nodes for the
secondary. This means that the path calculation of the secondary is
not
anymore 100% bound to the primary. Also I would prefer that the ARO
is more
like a "hint" than the real path. With this, you do not have to
interaction
problems with re-optimization of secondary, crankback, ... For
instance:
when the secondary fails, it can be re-established ignoring the ARO.
Or
when the secondary can be re-optimzed between border nodes, then it
can be
done without impacting the primary or when the global
re-optimization is
possible, then the ARO can be simple ignored. 

I prefer to have the ARO only recording border nodes, and optionally
only
acting as a hint for the ingress LSR. The latter is less important
to me.

4) text below figure 3: primary has to be as short as possible. I do
not
care much about the secondary becuase it is almost never used. Also,
the
resources that it reserves can be shared with other secondaries. The
problem here is: what are you optimizing? According to me the path
of the
primary has to be optimized.

5) I do not understand why the ARO has to contain Area-Ids to
indicate the
route. If the ingress can put the "area-path" in the ARO, then it
can also
put the border nodes in the ERO of the secondary immediately. I.e.
refering
to figure 5: A knows that the path of the secondary is A1-A2-A5-A6.
How
does A know this? And if it is possible to let A know this
information,
then why could it also not know that the path is B1-B7-B9. If A can
do
this, then there is no need anymore for ARO. So the basic question
is: what
makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This
means
to me that section 4.2 is not valid and that the ARO assumes that
the
"area-path" of primary and secondary is the same, which is true for
IGP
areas. See also comment 2. Maybe better to remove the AREA-IDs from
the
ARO.

6) step 1d page 14, second last line: how does the ABR know that B7
has to
be used and not B8?

7) section 4.3: also describe the L-bit that is in the ERO
subobjects.

8) Is the Addr_len in for instance subobject 1 always 32 or can it
be
something else. I agree here that you should re-use ERO subobjects
but I
see that you are doing this.

9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that
conflicts with what is described in the middle of page 19 where the
numbers
are 32, 33, 34.

10) the text in section 4.3.3 is rather confusing (the part in the
middle
of page 22, about pruning the nodes). Take figure 5, area 5: If B6
has to
calculate a path from B6 to B10, then this path can pass via B5, B8,
B7
and/or B9. This is because border nodes can also act as core nodes
at the
same time. This seems to be excluded from the draft. Is that
correct?

11) First refinement in section 5 about the cost of virtual links:
this has
been proposed before in
http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-mpls-te-02.txt
which is not a good idea: it only works for inter-IGP area and it
decreases
the scalability although it also has some advantages.

12) (!) There are conflicts with re-optimization, crankback,
re-establishement after failure of secondary LSP, ... because in all
of
these cases a working primary LSP also have to be re-signaled which
is not
good. Therefore it is better to let the ARO only record border
nodes,
and/or to use the ARO more as a hint for the secondary: using the
ARO in
the primary makes sure that a trap is avoided, and then it is up to
the
signaling of the secondary to find this path by using crankback,
.... There
is no need that the primary LSP also gives the path, it only has to
make
sure that there is a path.

13) (!) The method seems not to be applicable for inter-AS
calculations.

14) Following the classification of methods (ARO, XRO, PCE) that you
described earlier on ccamp based on parallel/sequential and
distributed/centralized computation, ARO looks more an alternative
for PCE than for XRO? In fact, would it be possible to combine
methods? It would be good to explain the interaction (if any) with
these other methods.

Hope this helps,

regards,

Stefaan

---

From: "Vishal Sharma" <[email-masked]>
Date: Thu, 22 Apr 2004 23:03:45 -0700

Hi Stefaan,

Thanks a lot for looking over the draft so carefully, and for your
many detailed comments.

While we will address the individual comments once we've digested
them a bit (and in a separate email to avoid making this one
too long :-)), let me try to address a couple of the most important
points raised in your note below.

1) Recording only border nodes:

Actually, if one only recorded border nodes, then upon signaling
the secondary, the ingress border node for the secondary has no
idea about the intra-area (or intra-AS)  path of the primary (in its
own area or AS), and therefore cannot ensure that the primary and
secondary segments are in fact disjoint.

This was a point I discussed with several other people
(who initially proposed the same thing), including
Arthi and Adrian, but we concluded, for the reason above, that merely
recording the border nodes does not work for diversity. As a
result, the ARO does, in fact, serve a very useful purpose.

We can of course think more about what the trade-offs are, and see if there
is some way to retain the main advantage of the proposal (diversity,
joint optimization of both paths) while also recording less information.

2) With regard to optimizing only the path of the primary, I am not
so sure about doing just that.

I believe one can get into real problems if one does not constrain
the path/cost of the secondary, with unduly long secondaries that
will greatly limit the ability to setup further primaries
(and secondaries). (This can be especially true of tranport networks,
where one would set up very large bandwidth pipes, and optimizing their
placement would be critical.)

This scheme is optimizing jointly the cost of the primary and
secondary, while ensuring diversity.

I think you will find that most providers would be equally concerned
with the cost/placement of the secondary path.

Moreover, as I emphasized (and as discussed during CCAMP we wiil change
the title and our intro. to reflect that), this is a:
generic method for computing diverse paths
that meets a variety of requirements: load balancing, multipe paths
when a single one has insufficient capacity, multiple paths between
VoIP gateways, etc. in all of which one would ideally be looking for
paths with about equal length.
Protection is just _one_ application of this scheme.

3) Re-optimization, crankback, and failure of secondary:

I think the scheme works with all of these, and does not really
conflict with any of them.

With crankback, there should be no problem, whenever a crankback occurs
on the primary, the secondary will also be recomputed at the ASBR/ABR
to which there is crankback.

With re-optimization, there are several options.

-- Either default to sequential calculation, and use the XRO to re-optimize
whichever of the two diverse paths requires re-optimization.
(This might be an immediate response, while the below could be
a more long-term response.)

-- Or, if the goal really is joint optimization, the provider will have
to setup a new set of diverse paths, and use make-before-break to
transition the traffic over.

-- If the secondary fails, again there are two options. Either use
the XRO to perform another path setup (and, possibly, re-optimize
the paths later), or use the joint optimization method above with
make-before-break.

4) Relationship to XRO:
As I mentioned in the Seoul presentation and also
in our discussion, I think the XRO has many uses -- during computation
after crankback, to enable adminstrative routing/re-routing, protection,
etc.

So I think the ARO and XRO are actually complementary.

Regards,
-Vishal

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, April 19, 2004 12:08 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: comments on ARO
>
>
>
> Hi Vishal,
>

---

From: [email-masked]
Date: Mon, 26 Apr 2004 18:25:30 +0200

Hi Vishal,

please find some more comments inline...

> joint optimization of both paths) while also recording less information.

The problem I want to solve here is NOT to reduce the amount of
information in the ARO, i.e. my purpose is not to reduce its length.
Rather, by only recording the border nodes you give more freedom
when signaling the secondary (using the XRO!) meaning that when
crankback or re-optimization of the secondary is possible, the
primary does not have to be resignaled to get a new ARO. 

> secondary, while ensuring diversity.

My question was *what* is the metric being optimized. For instance
with sequential computing, the cost of the primary is minimized,
while the second metric is the cost of the secondary LSP. With
parallel computing it is different: is the cost being minimized the
cost of primary + cost of secondary, or is it something else?

> Protection is just _one_ application of this scheme.

This load balancing over multiple paths looks like a good
application.

> a more long-term response.)

Since an ABR on the secondary path only sees a full strict path in
the ERO, the ABR does not know when there is a better path matching
the constraints. This is because the ABR does not know the
constraints.

> the paths later), or use the joint optimization method above with

This looks ok.

regards,

Stefaan

---

From: "Vishal Sharma" <[email-masked]>
Date: Mon, 26 Apr 2004 13:18:52 -0700

Hi Stefaan,

Just following up on my earlier reply to your comments.

We had promised to respond to your specific comments 
a bit later, and some respones are in-line.

Again, thanks a lot for feedback, it will be very 
helpful in revising the document.

Regards,
-Vishal

PS: A couple that are not addressed here, we will address 
jointly with others, such as when responding to Arthi's
or JL's comments, and will CC you on them.

> understand that this is not an assumption?

Your understanding is correct. That is, we do _not assume_ that
the primary and secondary paths (or the two diverse paths, to
be more accurate) follow he same areas/ASs.

Thanks for the observation, we will make this clearer in the
next revision.
> clear which path is selected in area 3: I guess it is E-G-H for

Yes. Thanks for pointing this out, we will specify it clearly
in the upcoming revision.

> acting as a hint for the ingress LSR. The latter is less important

As explained in my earlier response, 
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html
a difficulty with just recording
the border nodes is that mere knowledge that the secondary is for
some primary, without a knowing the path of the primary is not
sufficient to ensure _diversity_ of the two paths.

This is one of the main goals of the ARO scheme, thus we need
to have knowledge that a primary _and_ a secondary are to
be routed when jointly computing their path at each border node.
 
> primary has to be optimized.

Addressed in detail in my earlier response
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html.

Briefly, with diversity as the goal, often it may be that the
paths of both the primary and secondary are to be optimized
or made as short as possible, so we cannot just optimize
the one path while ignoring completely the other.

(Even if not, one can get into real sub-optimal network 
operation with unduly long secondary/diverse paths, if their
lengths are not controlled cleverly from the start.)

But, I agree, we will make this clearer in the revised version,
when we focus on diversity, and clarify that protection is one
application of the scheme.

> 6) step 1d page 14, second last line: how does the ABR know that B7

Referring to Fig. 5 of the draft, the ingress ABR in Area 2 
would make that selection depending on what metrics it is
optimizing.

> 7) section 4.3: also describe the L-bit that is in the ERO

Ok, thanks, we will in the next revision.

> see that you are doing this.

As mentioned in Sec. 4.3.2.1, the address length allows the IPv4
address to be a prefix of length specified by the "Add_Len" field.
So the address length can be different than 32.

> conflicts with what is described in the middle of page 19 where the

Thanks for the catch! We will make these consistent.

>the scalability although it also has some advantages.

Thanks for the observation and the pointer. As you would see
from my response to JL, we are thinking more about the virtual
link case, and will be able to post some alternatives once
we have given it a bit more thought.

>good. 

Actually, there are several options in each of these cases, and
I have explained some in my earlier response
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html.

Further inputs from CCAMPers 
on interworking these will be much appreciated.

We can probably add a discussion of some of these interworking
options in the draft, although it is not a goal of the draft
to document all possible interworking scenarios!

>Therefore it is better to let the ARO only record border
>nodes,

As explained above, and in my earlier response, the goal is to
ensure that there is a _diverse_ path, not just a path for the
second LSP.

>13) (!) The method seems not to be applicable for inter-AS

Not sure why you say that (perhaps because of point 12?). We have
designed it to be applicable both for inter-area and inter-AS cases.
While some refinement for the inter-AS case would improve the
scheme, we certainly had that inter-AS case in mind when developing
it.

>methods? It would be good to explain the interaction (if any) with

As I pointed out in my email to JP, 
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html

we view the ARO as complementary to the PCS/PCE approach and
to the XRO. The goal in designing it wasn't really to replace
either of these.

In fact, I explained there that the ARO is a hybrid approach
that can 
can compute end-to-end diverse paths like in the PCE approach, with the 
simplicity of the per-domain approach, and without any changes 
to the signaling protocols (save for an ERO-formatted
ARO obj.).

As said earlier, it seems it would be useful for us to put
in a short section discussing complementarity with other approaches.

You already saw some of this in my earlier response to your email,
where I explained how things could work with crankback, re-opt. etc.

---

From: "Vishal Sharma" <[email-masked]>
Date: Wed, 28 Apr 2004 21:35:01 -0700

Hi Stefaan,

Thanks for your follow-on inputs. Few comments in-line.

We look forward to any additional feedback you have.

Regards,
-Vishal

> Sent: Monday, April 26, 2004 9:26 AM
> To: [email-masked]
> Cc: [email-masked]; Fabio Ricciato; Ugo Monaco; Alessio D'Achille;
> Marco Listanti
> Subject: Re: comments on ARO
>
>
>
> Hi Vishal,
>

Sure, I understood that the goal wasn't to reduce the length of
the ARO per se, but rather the level of detail that would need to
be recorded in it (regardless of the actual amount of data the ARO
would carry).

If you recollect the classification of path computation models
I gave in my email to JP
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html

we have under distributed computing: i) a parallel path computation
model and  ii) a sequential one.
ARO achieves the former, while XRO achieves the latter.

So, if one did not compute and record the path of the secondary
jointly with the primary (and only recorded the border nodes instead)
the scheme would reduce to a _sequential path computation_, with its
attendant drawbacks (sub-optimality, trap topology, etc.).

The beauty of the ARO scheme is that it can compute end-to-end
diverse paths using a parallel path computation model (albeit distributed
at each area/AS), with the simplicity of the  per-domain approach, and
without any changes to the signaling protocols.

Please note also that this does not say anything about the usefulness of
the XRO (which _is_ a v. useful construct, with several applications, as
pointed out in my earlier email), only that when paths are computed
sequentially these problems arise.

> cost of primary + cost of secondary, or is it something else?

Minimizing the cost of the primary + cost of secondary is one metric
that a parallel path computation scheme may minimize. There might
be others. For e.g. minimize the cost of primary while keeping that
of secondary below a certain threshold, minimize the difference
between the costs of the primary and the secondary, and so on.

The actual criteria for minimization may be a provider choice,
that is executed/realized by the joint path computation algo.
employed in the network nodes.

> This load balancing over multiple paths looks like a good

Great, thanks. This is why JL and others have asked us to
not limit our scheme only to restoration applications.

And we will do this generalization in the update.

> > the paths later), or use the joint optimization method above with

Great, thanks. We will add this discussion to our revised
draft.

---

From: ricciato <[email-masked]>
Date: Thu, 29 Apr 2004 08:19:40 +0200

Hi Stefaan,

in addition to Vishal´s comment,  just let me quote below a paragraph 
from my previous mail 
(http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00473.html, Mon, 19 Apr 
2004).

I´d appreciate to have you opinion on it.

ciao
Fabio

> 3. The joint-computation with ARO can be applied to a vast class of 
> problems dealing with path-pair computation. I'm giving below some few 
> examples.
> (I think this also adrresses some comment by Jean-Louis). In general, 
> in each problem of path-pair computation one can distinguish the 
> constraint(s) from the optimization objective:
>
> Case-I: find a pair of disjoint paths (i.e., disjointedness is a 
> constraint) wich minimize some link metric (hop-length, link-load, etc.)
> Case-II: find a pair of maximally disjoint paths (disjointedness 
> becomes an objective)
> Case-III: find a pair of disjoint paths P1 and P2 that minimizes the 
> difference |d(P1)-d(P2)|, where d() is some metric associated to the 
> path (e.g., delay....might make sense in optical networks ??).
> Case-IV: Assuming that for each link pair (i,j) it is possible to 
> assign a "correlation" factor r(i,j) accounting for the probability of 
> contemporary failures, find a pair of paths that minimizes the 
> max{r(i,j)} over all pairs such that i is in P1 and j is in P2 [see 
> note 2].
>
> Maybe not all the above items are of practical interest in real 
> applications, but the fact that our approach encompasses all of them 
> proves the flexibility and usefulness of joint-computation with ARO. 
> Several other problems can be found.
> In general, joint-selection with ARO can address to all problems 
> presenting some *joint constraints* and/or *joint optimization 
> objective* on the pair of paths.
>
> Needless to say, each such case requires ad-hoc route-selection 
> _algorithms_ to be implemented in the ingress border nodes (or in a 
> centralized server within each AS), but all can be accommodated with 
> the signaling procedure based on ARO.
>
> Admittedly, the current draft version exclusively focused on case-I, 
> and fails to make it clear that the set of possible applications is 
> far broader. We will improve this point in the future version. 
> Incidentally, I notice here that this is indeed the reason why we 
> proposed the (quite neutral) term "Associated Route Object" instead of 
> the more specific "Disjoint R.O." or "Backup R.O." etc.: we wanted to 
> leave it open to a broad set of possible applications.
>
> Maybe it would make sense to add some additional semantic in the PATH 
> messages that specify the contraint(s) and/or the objectives to which 
> the primary (in the ERO) and secondary (in the ARO) paths should 
> (jointly!) comform.
> This might be an associated sub-object of the ARO, perhaps ?
> Might be named "Route Pair Requirements" (RPR) ?
> In other words, the overall semantic in the PATH messages should sound 
> like:
> "compute a primary route segment (in the ERO), and an associated 
> secondary route segment (in the ARO), such that they are subject to 
> the contraint(s) X and optimize objective Y (X,Y are contained somehow 
> in the RPR)".
>
> The ERO+ARO+RPR scheme, in the framework of distributed *joint* route 
> selection, would be really a quite flexible and general scheme.
>
> What do you think about that ?

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Thu, 29 Apr 2004 13:27:22 -0400

Hi Vishal,

Comments in line,

>without any changes to the signaling protocols.

Here is one of main concerns that I have about this scheme: by contrast 
with a distributed PCE-approach, a severe drawback with such a model lies 
in the potential number of retrials (since it has to be combined with 
crankback) and consequently the potential set up time. Indeed, you may have 
diverse paths within a domain, and then a set up failure in the next hop 
domain requiring to crankback in the previous domain; the number of 
potential trials may be really non negligible.

Moreover, you can still cannot guarantee and an end to end shortest path.

>employed in the network nodes.

Right - same comments applies to the distributed PCE-based approach,

>And we will do this generalization in the update.

We mentioned that application indeed in the requirements drafts.

JP.

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Thu, 29 Apr 2004 13:33:04 -0400

Hi Vishal,

Sorry for the burst of comments ...

[snip]

> > > to which there is crankback.

See my previous email about the set up time issue

> > > whichever of the two diverse paths requires re-optimization.

But then you may pretty likely fall back to the trapping problem ...

> > > transition the traffic over.

Looks to me as the only viable option if:
         -> You still want to limit the trapping problem,
         -> You implement any algorithm trying to optimize a set of 
constraints for both the primary and secondary.

Cheers

JP.

---

From: "Vishal Sharma" <[email-masked]>
Date: Thu, 29 Apr 2004 16:26:52 -0700

JP,

Thanks for the comments.

A comment and question in-line.

-Vishal

> From: Jean Philippe Vasseur [mailto:[email-masked]]
> Sent: Thursday, April 29, 2004 10:27 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Fabio Ricciato;
> Ugo Monaco; Alessio D'Achille; Marco Listanti
> Subject: RE: comments on ARO
>
<<snip>>

> Moreover, you can still cannot guarantee and an end to end shortest path.

<snipped to end>

We have to think a bit more about the idea of combining ARO with
crankback and need to get back after giving it some thought.

[Please note that the goal with ARO is not necessarily to guarantee
an end-to-end shortest path. Rather, it is to ensure that diverse
paths can be efficiently computed, while meeting certain constraints
per some metrics (as further explained in Fabio's email
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00562.html
and my recent reply to Stefaan
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00561.html)]

Reading draft-vasseur-ccamp-inter-area-as, especially Sec. 6.6
I was a bit unclear on how the computation proceeds.
(BTW, the draft will read much better if the generic steps are
explained first, and then the worked example. As it stands, the
two are intermixed, and it becomes much more difficult to understand
what the algo. is.)

The draft states that
"the PCE provides the list of shortest paths (with their corresponding
ERO (potentially partial ERO) + Path-cost) from _every_ ASBR to the
inter-AS TE LSP destination."

Suppose the destination is in ASn. PCEn computes a set of shortest paths
from _every_ ASBR in ASn to the destination, and passes them back to PCn-1.

What does PCn-1 do?

My understanding from the draft is that it computes a set of
shortest paths between all ASBRs that
connect ASn-1 to ASn-2 and those that connect ASn-1 to ASn, and
includes the inter-AS links between ASn-1 and ASn in those
shortest path computations.

My question is: what does PCn-1 send back to PCn-2?

Does it, in turn, send PCn-2 the set of all possible paths traversing
ASn-1 and ASn or does it concatenate all paths, choose the shortest
one, and send back one (the shortest path traversing ASn-1 and ASn)?

If the former, then we have a major scalability issue, as the
number of paths passed back to successive PCi's will grow,
literally exponentially, from AS to AS.

If the latter, the scheme may fail to select the shortest path,
as I explain below (which is not unexpected).

Take the following fig. from the draft (where I have added a link
between ASBR3 and ASBR5):

     <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ---->

               <---BGP--->            <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
      |\     \ |       / |   / |   / |          |      |
      | \     ASBR2---/ ASBR5  | --  |          |      |
      |  \     |  /----/ |     |/    |          |      |
      R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2

We will use the mechanisms specified in Sec. 6 of draft-vasseur, and
assume for this part of the discussion that the objective is to the
shortest path between R0 and R7.

As before, ASBR1, ASBR4, and ASBR9 are the PCEs for AS's 1, 2, and
3, respectively.

The request propagates from R0 to the PCE's, to ASBR1 on to ASBR4 on
to ASBR9, as before.

1. ASBR9 computes two paths:

ASBR9-R6-R7 Cost = 10, say
ASBR10-R7   Cost = 20, say (per some metric)

2. It passes these back to ASBR4, which in turn calculates that the
possibilities
to traverse AS2 are:

ASBR4-R3-ASBR7-ASBR9, Cost = 30
ASBR5-R3-ASBR7-ASBR9, Cost = 40
ASBR6-R4-ASBR8-ASBR10, Cost = 30
(Assume all other permutations have higher cost.)

3. Using the concatenation approach mentioned in the draft, it computes
that the shortest paths traversing ASs 2 and 3 is, therefore,

ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 40

4. It passes this back to ASBR1, which in turn calculates that the
possibilities
to traverse AS1 to reach ASBR4 are:

R0-X1-ASBR1-ASBR4, Cost = 50
R0-X1-ASBR2-ASBR4, Cost = 60
(There are other permutations, but assume their cost is higher.)

Also, assume that the path from R01 to ASBR5,
R0-R2-ASBR3-ASBR5 has cost = 30.

5. Again, using concatenation, ASBR1 calculates that the "shortest
path" is

R0-X1-ASBR1 -- ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 90
<--------------->   <------------->  <----->
       50                 30            10

However, there was a shorter path
R0-R2-ASBR3 -- ASBR5-R3-ASBR7 -- ASBR9-R6-R7, total cost = 80
<-------------->  <-------------->   <----->
       30                40             10

which could not get picked in this case.

For this, it would have to be that all possible paths are propagated
back to PC1, which then selects the shortest one among them, but
this, it seems to me, would be an operational and computational nightmare.

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Fri, 30 Apr 2004 08:36:05 -0400

Hi Vishal,

At 04:26 PM 4/29/2004 -0700, Vishal Sharma wrote:
>an end-to-end shortest path.

Yes I noticed that ;-) hence my comment that it cannot guarantee the 
shortest path

>Rather, it is to ensure that diverse

But my main concern remains: the number of required crankback required in 
some cases and the related impact on set up failure.

>CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6

What you described is not how the algorithm works ... All the shortest 
paths from the destination to every entry ASBR are computed in a backward 
and recursive manner (hence you progressively compute the SPT rooted at the 
LSP destination). Note that there are several variations and optimizations, 
I just described the general case that applies to the generic case of N 
ASes. I'll try to clarify in the next revision of the draft.

Cheers

JP.

---

From: "Vishal Sharma" <[email-masked]>
Date: Fri, 30 Apr 2004 11:09:10 -0700

JP,

Thanks for clarifying. Questions in-line.

-Vishal

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Jean Philippe Vasseur
> Sent: Friday, April 30, 2004 5:36 AM
> To: [email-masked]
<<big snip>>

> ASes. I'll try to clarify in the next revision of the draft.

In that case, I feel a much clearer exposition is needed in Sec. 6.6.
I had read it several times, but it wasn't clear that the algo.
works as described above.
(BTW, I will now think about things in the light of what you clarified,
and get back with any questions.)

In the meantime, I have few quick questions ...

-- Who decides on the initial AS path (and consequently
the sequence of distributed PCEs) that the request should traverse?
(Since there could be multiple paths to get from the source (and its
AS) to the destination (and its AS).)

There is a phrase at the start of Sec. 6.6, which says
"In the case of inter-AS TE, the PCE must
be able to serve the source AS and can compute inter-AS TE LSP path
terminating in the destination ASn."

So, is the first PCE assumed to make that selection of AS's?

-- On what criteria is this decision based?

-- Also, if the SPT rooted at the destination is the one being computed,
why does the text show "trees" rooted at ASBR4 and ASBR1, respectively?
Instead (or in addition), it should show an example of what the final
SPT, rooted at R7, looks like.

-- And, why do the two "SPT's" illustrated have loops?

-- Also, at one point (after the fig. for the "SPT" rooted at ASBR4) the
text says
"The cost of the ASBR-ASBR link between ASBR of different ASes is also
known by the PCEi (see section 6.2)."

I assume this means the cost of ASBR-ASBR links that connect the current
AS to its neighboring AS's?

-- And is 6.2 the intended section being referred to? Since 6.2 merely
has a paragraph explaining what a PCE is.

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Fri, 30 Apr 2004 14:20:24 -0400

Hi Vishal,

>Thanks for clarifying. Questions in-line.

I'll try to clarify in the next revision of the draft (probably for 
IETF-61). As for the PCE discovery, IGP extensions have been proposed and 
BGP ones are on their way. The actual selection could be achieved by 
various means.

Cheers

JP.