Subject: RE: TE Requirements Draft - ELSP

From: [email-masked]
Date: Wed, 21 Nov 2001 08:15:07 -0000

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:[email-masked]]
> 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.
> 
>

---

From: "Sudhakar Ganti" <[email-masked]>
Date: Wed, 21 Nov 2001 14:30:24 -0500

Thanks Neil for your comments. per-OA SLAs within
an E-LSP and protection were one of the motivations in
seeking the per-OA signaling requirements for E-LSPs.
Specially I see the usefulness of this in L2VPN deployment.
With L2VPNs, one may want to provide end-to-end services
with single E-LSP (easy for maintenance, protection and
restoration) and yet guarantee SLAs for multiple classes
within that E-LSP. I don't think this can be achived
easily with exisitng solutions.

-Sudhakar

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of [email-masked]
> Sent: Wednesday, November 21, 2001 3:15 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 22 Nov 2001 10:45:24 +0100

Neil,

could you check below I got it right:

> > need some 'effective BW' and 'survivability' attribute.

Is it correct that what you are describing here is the ability to transport 
multiple OAs on a single LSP and have the path for this LSP be computed 
based on one "effective Bw" for that LSP , and have one single 
survivability policy/attribute (as opposed to one independent survivability 
policy/attribute for each OA)?

Thanks

Francois

>  L-LSPs
> > can also be

_________________________________________________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone:          +33 4 97 23 26 19
Mobile :               +33 6 89 108 159
Fax:                   +33 4 97 23 26 26
Email:                 [email-masked]
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410  Biot - Sophia Antipolis
FRANCE
_________________________________________________________

---

From: Nabil Seddigh <[email-masked]>
Date: Thu, 22 Nov 2001 13:21:53 -0500

Francois,

I am not sure you would necessarily want to use one "effective BW"
for the entire LSP. Each OA would have its own "effective BW".
The translation into "effective BW" is different for different
types of PHBs. I would state the requirement in Neil's example as:

- transport multiple OAs on an LSP 
- one survivability attribute for the entire LSP
- compute path for single LSP based on knowledge of BW requirements 
  for each OA to be sent on the LSP and knowledge of the resource
  availability for each OA on links.

Best,
Nabil

> Is it correct that what you are describing here is the 
> ability to transport multiple OAs on a single LSP and have the 
> path for this LSP be computed based on one "effective Bw" for that 
> LSP , and have one single survivability policy/attribute (as 
> opposed to one independent survivability