RE: What we disagree on RE: TE Requirements Draft-ELSP

["Roberto Mameli (ERI)" <Roberto.Mameli@eri.ericsson.se>]

Francois,


> -----Original Message-----
> From: Francois Le Faucheur [mailto:flefauch@europe.cisco.com]
> Sent: Thursday, December 06, 2001 6:02 PM
> To: Shai Herzog
> Cc: 'Francois Le Faucheur'; 'Siva Sivabalan'; 'te-wg@ops.ietf.org'
> Subject: RE: What we disagree on RE: TE Requirements Draft-ELSP
> 
> 
> Today when doing Aggregate TE in a Diff-Serv network, network 
> administrators effectively group all their OAs on a single 
> E-LSP with a 
> single set of attributes. It's pretty coarse but it's actually quite 
> appropriate in many environments. In some environments (the 
> ones which are 
> interested by DSTE), this is felt a little too coarse and 
> they'd like to 
> separate some OAs (typically EF). But it's not rididulous to 
> keep some OAs 
> together from teh CSPF viewpoint.



This point is very good. My question is: "What does aggregate TE really means?". The only definition I have been able to find is reported in appendix A3 of the MPLS-DIFF draft, quoted below:

	A Service Provider running 8 (or fewer) BAs over MPLS, performing aggregate Traffic 	Engineering (i.e. performing a single common path selection for all BAs), using 	aggregate MPLS protection (i.e. restoring service to all PSCs jointly)........

Based on the previous lines, we can define "aggregate TE" as the form of Traffic Engineering that is constrained by common path selection among different service classes, independently from any other factor (such as the relative proportion of traffic across
classes).

This definition could also include scenarios in which a routing algorithm calculates a SINGLE path for all service classes given N bw costraints. Of course, the N constraints could be implicitly known by all nodes, in the form of preconfigured proportion of traffic across classes, without being signaled across network nodes. However, in my opinion this doesn't really allow Traffic Engineering in the network, and as Shai was trying to point out it is not really TE, but simply DiffServ (I quote Shai's words below):

	So, basically, if you use multiple OAs in an E-LSP, many other parameters
	(like BW, CSPF) become useless (and not permitted). This means such E-LSPs
	are only good for vanilla DiffServ (no signalled BW, no constraint routes,
	etc.). I'm not sure how usefull this could be for TE purposes.


So now it seems to me that there is something that is conflicting. We say that:

(A) E-LSP carrying multiple OAs are useful for aggregate TE (without specifying in detail what aggregate TE really means)

	AND

(B) if we use multiple OAs in an E-LSP (without per OA bw constraints), then we simply provide DiffServ, not really TE

It seems to me that (B) contradicts (A), unless there is something that I'm missing. The original idea of signaling per OA bw constraints within an E-LSP was motivated by the need to solve this contradiction.

/Roberto