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

From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Date: Thu, 27 May 2004 15:26:11 +0200

Hi Tony

Please see inline

Regards

JL

>-----Message d'origine-----
>De : Tony Li [mailto:[email-masked]] 
>Envoyé : mercredi 26 mai 2004 22:37
>À : Adrian Farrel
>Cc : LE ROUX Jean-Louis FTRD/DAC/LAN; [email-masked]; 
>[email-masked]
>Objet : Re: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
>
>
>> I accept that full leakage of all TE information in a dynamic way
>> would almost certainly
>> have a major impact on IGP scalbility.
>>
>> I do not accept that some carefully considered leaking of aggregated
>> TE information on a
>> sparse timer basis would necessarily have such a dire impact.
>>
>> This is why I want the requirements draft to tell me what impact on
>> the IGP I am allowed
>> to have and leave CCAMP to derive a solution that fits that 
>> requirement. I don't think it
>> is right to tell CCAMP what solutions it may or may not consider.
>>
>
>
>Operator hat on:
>
>I would very much like to see it be a requirement that no information 
>is leaked
>without specific configuration.  Further, I would very much like to see
>implementations give us reasonable granularity (and reasonable 
>abstraction) in
>what we choose to leak.
>
>As an example, I would like to be able to leak detailed topology 
>information from
>my IS-IS L2 database down into an L1 area.  I would NOT want to leak 
>bandwidth
>information.

I don't see the gain, as regards inter-area TE, 
in leaking detailed topology information from L2 into L1 without leaking any bandwidth information...

>I would want to leak an abstraction of another L1 area 
>down into an
>L1 area, but I would definitely want that to be an 
>abstraction, NOT the 
>full
>database.

Of course, else you come back to a single area network !
But IMHO such abstraction, to be useful, i.e. to allow computing an inter-area TE path,
would require to take into account a large set of constraint combinations, 
and this would likely lead to major impact on IGP scalability. 

>
>I am not interested in perfect optimality.  I am interested in 
>what can 
>be
>achieved with a limited amount of overhead.  It is very clear that 
>there cannot be
>any improvements without some impact on IGP scalability.  

Not so sure, there are schemes that allow computing an optimal inter-area path without adding any byte in LSA/LSP...

>If nothing 
>else, every
>byte in an LSA/LSP counts towards router memory consumption.  Thus, we 
>have a
>tradeoff that we need to make and perfect optimality is not a 
>reasonable goal in
>light of limited scalability.  Good returns can be had by leaking 
>information
>that is topologically "close by" and abstracting distant information.  

See above comments on TE abstraction

>If

>necessary, this can be supplemented by path manipulation along the way.
>
>Regards,
>Tony
>
>

---

From: Tony Li <[email-masked]>
Date: Thu, 27 May 2004 12:44:00 -0700

> leaking any bandwidth information...

The gain is that the bandwidth information is in continual flux, and 
leaking
that just sloshes L1.  Plus, by the time signaling gets there, the 
information
will likely be out of date.

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.

Again, what I'm suggesting is just an example of one overhead vs. 
optimality tradeoff.

> and this would likely lead to major impact on IGP scalability.

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.  However, the L2 router would be responsible for 
computing
the remainder of the path, and the L2 router would have current 
information
about L2 and some topology information about the destination L1 area.  
It
might compute a path that transits L2 optimally and also selects the L2
exit router.  The L2 exit then computes an optimal transit of the L1 
destination.

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