Subject: RE : RE : RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt

From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Date: Fri, 28 May 2004 10:48:26 +0200

See inline

>-----Message d'origine-----
>De : Tony Li [mailto:[email-masked]] 
>Envoyé : vendredi 28 mai 2004 10:19
>À : LE ROUX Jean-Louis FTRD/DAC/LAN
>Cc : Adrian Farrel; [email-masked]; [email-masked]
>Objet : Re: RE : RE : Last call for 
>draft-ietf-tewg-interarea-mpls-te-req-01.txt 
>
>
>>> Combine this with the fact that the primary reason to use this 
>>> information is to ensure an optimal exit from the L1 area, 
>and there 
>>> doesn't seem like
>>> a real need to worry about instantaneous capacity.
>>
>> But an optimal exit, as regards cost, may not allow to find 
>a feasible
>> e2e path, if there is not enough capacity from
>> this exit to the destination.
>>
>
>
>Certainly true.  However, in a practical sense, the area is connected 
>via redundant
>L1L2 routers.  The redundancy is there so that neither is a single 
>point of failure.
>Thus both ABRs can pass the full traffic load of the area into the 
>backbone.  In short,
>engineering is sufficient to guarantee that we have enough fiber.

OK, and what happens if I have N ABRs, at an area border, with N> 2, which is actually likely to happen.
Do you still make the assumpption that each ABR can pass the full traffic load of the area ??

>
>
>>> You're making the assumption that the head end of the LSP 
>is computing
>>> the entire
>>> path.
>>> Again, I'm advocating a somewhat different position (ala
>>> Nimrod): the path
>>> is computed with more refinement as you get closer to the
>>> destination.
>>> The
>>> head end might be able to provide an explicit path through the
>>> originating L1
>>> area, and based on its L2 topology information, it might select the
>>> exit point
>>> from that area.
>>
>> Based on which information does the Head End select the ABR ?
>
>
>L1 TE information plus L2 topology.
>
>
>>> By chaining together 3 locally optimal paths, we will NOT
>>> achieve global
>>> optimality, but we will get a good first approximation for 
>a fraction
>>> of the cost.
>>
>> Not so sure that such scheme will get a good first 
>approximation for a 
>> fraction
>> of the cost.
>> The ABR selected by the Head-End based on its L1 and L2 information 
>> may be the worst ABR, as regards the end-to-end path.
>> Actually you can definitely not control that. Further more 
>such scheme 
>> cannot avoid cranckback risks,
>> and it seems from your last comment that you want to avoid that...
>>
>> Let's take the following example
>> A1, A2, A3, A4 are ABRs
>> Area0 topology is leaked into Area1 and Area2.
>> All metrics are set to 10 except A1-A2 metric that is set to 1
>> Avaialble bandwidth is 100M on all links except on link A2->R5, 
>> A1->A3, and A2->A4 where available bw=50M
>>
>>  Area1          Area0       Area2
>>   --------A1--------A2--------
>> R1         |         |        R5
>>   --------A3--------A4---------
>>
>> We want to setup a TE-LSP from R1 to R5 with bandwidth 60M
>> R1 selects an ABR based on Area1 and Area0 topology info. With your 
>> scheme it may select A1
>> Then A1 will select A2, and A2 will find that there is no 
>path to the 
>> destination,
>> Then Crankback on A1 => No path to destination.
>> Then Crankback on R1 that selects A3....
>
>
>a) Per the above, this is an unacceptable network design in the first 
>place.

See above comment

>b) R1 has metric information for Area 0, so it would naturally select 
>A3.

Not so sure, as A1-A2 metric = 1 it would rather naturally select A1

>
>
>>>> Not so sure, there are schemes that allow computing an optimal
>>>> inter-area path without adding any byte in LSA/LSP...
>>>>
>>> Which would take us back down the crankback path.  No thank you.
>>
>> I was refering to PCE approaches where the inter-area path 
>is selected 
>> thanks to
>> a recursive CSPF computation on ABRs. Such schemes allow 
>computing an 
>> OPTIMAL path, without any IGP extension and without crankback...
>
>Sorry, I'm not sure I'm understanding you.  Are you suggesting 
>off-line 
>path computation?

No, computation can be distributed on ABRs. This is basically the scenario 4 of 
draft-kompella-mpls-multiarea-te :
"The head-end LSR requests one of the ABRs in the head-end area to
   compute a path to the destination. When the ABR in the head-end area
   receives the request, the ABR requests one of the ABRs in the tail-
   end area to compute paths to the destination from all/some of the
   ABRs in the tail-end area. Once the ABR in the head-end area obtains
   this information from the ABR in the tail-end area, the ABR in the
   head-end area could compute the path through the head-end and the
   backbone areas, concatenates the results of this computation with the
   appropriate path through the tail-end area, and then return the
   result to the head-end LSR."

Regards,

JL

---

From: Tony Li <[email-masked]>
Date: Fri, 28 May 2004 02:39:47 -0700

>    result to the head-end LSR."

Well, yes, that could be made to work.  Pretty ugly tho (sorry Kireeti 
;-).

Again, I'm happy to make the tradeoff of less work for less optimality.
If I'm that concerned about optimality, then I'll do offline computation
and static configuration.  Or human intervention.  I'm not interested in
spending the rest of my life debugging an incredibly complex solution 
that
gives me the last 0.0001% of optimality.

Tony

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 28 May 2004 09:24:20 -0700 (PDT)

On Fri, 28 May 2004, Tony Li wrote:

> > No, computation can be distributed on ABRs. This is basically the
> > scenario 4 of draft-kompella-mpls-multiarea-te :
...
> Well, yes, that could be made to work.  Pretty ugly tho (sorry Kireeti

Hey, I'm with you -- the scenarios are ordered roughly by preference
(i.e., Scenario 1 is my preferred option.)

> Again, I'm happy to make the tradeoff of less work for less optimality.

Agreed.

Kireeti.
-------

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Fri, 28 May 2004 15:59:53 -0400

Hi Tony,

At 02:39 AM 5/28/2004 -0700, Tony Li wrote:
>Well, yes, that could be made to work.  Pretty ugly tho (sorry Kireeti ;-).
>
>spending the rest of my life debugging an incredibly complex solution that

perfectly acceptable point of view of course. If optimality for 
inter-area/AS TE path is not required, just go ahead with ABR selection 
based on local knowledge but the point of the discussion was to mention 
that leaking of partial (topo) or summarized (TE-related) will always have 
an impact on your IGP and never guarantee you to get the shortest path.

JP.

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Fri, 28 May 2004 16:31:21 -0400

>Hey, I'm with you -- the scenarios are ordered roughly by preference

this was not the intention in the draft though ;-)

JP.

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 28 May 2004 18:44:56 -0700 (PDT)

> this was not the intention in the draft though ;-)

Actually, it _was_ the intention.

Kireeti.
-------