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

["LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@francetelecom.com>]

See inline

>-----Message d'origine-----
>De : Tony Li [mailto:tony.li@tony.li] 
>Envoyé : vendredi 28 mai 2004 10:19
>À : LE ROUX Jean-Louis FTRD/DAC/LAN
>Cc : Adrian Farrel; te-wg@ops.ietf.org; ccamp@ops.ietf.org
>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