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

Hi Tony,

At 01:19 AM 5/28/2004 -0700, Tony Li wrote:
>>>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.

The case of not being able to find a path is of course not the only one. 
What if one ABR finds a path which turns out to be much longer because of 
the bw constraints ? You'd be in a situation of leaking connectivity info 
with some impact on the IGP but because you do not have bw info, you would 
in many cases get a non optimal path. Hence the requirements for not 
leaking (summarized) connectivity/TE-related info. Indeed, this looks like 
the worst compromise: you would end up impacting your IGP without being 
able to guarantee anything in term of path optimality (not mentioning the 
need for crankback as pointed out by Jean-Louis).


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

But again, leaking for L2 topology would not help at all since we may 
select an L1L2 which may have to select a much longer path due to the 
constraints to respect so why leaking L2 topo at the first place ?



>>>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.
>b) R1 has metric information for Area 0, so it would naturally select A3.

Well no because the shortest path based on the metric would be via 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 Jean-Louis refers to the scenario 1 of draft-vasseur-ccamp-inter-area-as-te

JP.

>Tony
>
>