RE: TE Requirements Draft - ELSP

["Joel M. Halpern" <joel@stevecrocker.com>]

The CAC is not the problem.
The CSPF, and the source of the information for the CSPF, is the 
problem.  Not only do you have to give the requirements to the CSPF 
algorithm (a local process, or a central one, or ... but anyway not what we 
are discussing), but you also must include all N individual bandwidth 
requirements in your request.  That is, when you signal the LSP you must 
tell the network how much bandwidth you will use for each class within the 
LSP.  This is necessary for two reasons:
1) The CSPF information may have been out of date, and therefore must be 
checked per link per class
2) Each link needs to update its per class utilization information, and it 
can only do so if you provide sufficient information.

Therefore, what you have done is NOT signal one TE LSP, but rather to 
signal N LSP with the requirement that they be routed, protected, and 
re-routed together.  You got no effective scaling benefit because all the 
bookkeeping has to look at these as separate LSPs.

Hence, the capability you are asking for is the capability to signal an LSP 
bundle that is to be treated together.  That is an interesting feature, but 
not a trivial extension to what we have if it is to be done right.

Yours,
Joel M. Halpern

At 07:45 PM 11/20/01 +0100, Roberto Mameli (ERI) wrote:
>So, it seems to me that aggregate TE simply means that I choose a single 
>path supporting all BAs, with the same protection/restoration options. 
>This does not automatically preclude that CSPF and CAC require  per-PSC 
>bandwidth information as an input. I simply give N bandwidth requirements 
>(one for each of the N classes) to the CSPF algorithm, and it gives me 
>back a SINGLE path capable of carrying all the BAs. If my CSPF would run 
>based only on the E-LSP aggregate bandwidth I would not be able to choose 
>between two different paths with the same total occupancy... see again my 
>previous example, where each link is preconfigured to 50% in all the 
>routers (not reserved, simply preconfigured). In that example I do NOT 
>make aggregate reservation... I have preconfigured BW in every node and 
>simply need some additional information to choose the best way to route 
>the new LSP.
>
>However, my point is that I don't want to force the SP to use E-LSP. I 
>just want to say that, since E-LSP exists, a provider could be interested 
>to use it (for whatever reason). If E-LSP cannot be used for nothing more 
>than pure DiffServ, than there is no reason to have E-LSP. Just set up N 
>L-LSP instead of a single one carrying N OAs. But if we think that E-LSP 
>are really useful we cannot bias the standards towards a specific solution.