RE: TE Requirements Draft - ELSP

[neil.2.harrison@bt.com]

Joel/Roberto.....One reason why E-LSPs might of interest to operators in the
context of VPNs noting that:
-	DS classes only provide information on the up-state QoS forwarding
treatment......they cannot distinguish between one pkt's survivability needs
over another pkt of the same or different DS class.  However, I can easily
imagine many cases where voice/data applications may or may not be mission
critical both within the same, and across different, VPNs....and only the
customer really knows this;
-	if we have LDP deployed with like-DS-class aggregation across all
VPNs then it will not be easy (impossible?) to offer robust and measurable
separate availability and QoS SLAs to such VPN customers;
-	I would also argue that VPNs customers don't care about other
VPNs.....they only care about their VPN and expect the operator to be able
to look after the VPN as an entity (ie a whole) rather than a set of pkts
treated in isolation;
-	the current solution (sic) is to over-engineer networks, at least
for certain classes.

So one possible use of E-LSPs therefore might be to provide VPNs where per
VPN SLAs are required on availability and QoS.  To do this ER E-LSPs would
need some 'effective BW' and 'survivability' attribute.  L-LSPs can also be
used, but these simply increase the label/LSP requirements and one still
needs some overall encapsulation of the constituent L-LSPs (on a per VPN
basis).

I know this is not exactly what you guys are discussing wrt DS/TE for
E/L-LSPs, however it is something I think operators should be interested in
wrt E-LSPs and their potential usefulness.

regards, Neil



> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@stevecrocker.com]
> Sent: 20 November 2001 19:18
> To: Roberto Mameli (ERI); TE WG
> Subject: RE: TE Requirements Draft - ELSP
> 
> 
> 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.
> 
>