RE: TE Requirements Draft - ELSP

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

[Reformatted to convince the mailer to accept it...]

We already have a way (with two sub-cases) to meet the 
requirement.  Fundamentally, if you want to engineer the EF traffic 
separately from the BE traffic (which seems a sensible thing to do) then do 
so.  Insisting on using shared LSPs but separate advertisements and 
engineering does not seem a noticeable improvement.  To quote (or mangle a 
quote from) several good people:
Perfection is achieved when there is nothing left to remove.

To put this differently, if you really are trying to engineer the paths 
separately, it seems equally likely that you will get cases where the 
composite LSPs do not take the right path, and you need separate 
ones.  Forcing them together strikes me as bad advice to the service provider.

IETF experience is that options (particularly very similar but not 
identical options that meet the same goals) are dangerous and 
counter-productive.  If we really need this option, there ought to be a 
clear reason that is not met by the existing tools.

Thank you,
Joel M. Halpern

At 06:53 PM 11/19/01 +0100, Roberto Mameli (ERI) wrote:
>Hi Francois and all,
>
>I do not completely agree with you. Please see my comments below.
>
> > -----Original Message-----
> > From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> > Sent: Monday, November 19, 2001 5:49 PM
> > To: Choudhury, Sanjaya
> > Cc: 'Francois Le Faucheur'; Jim Boyle; TE WG
> > Subject: RE: TE Requirements Draft - ELSP
> >
> >          - if I want to do aggregate TE in my network, then I
> > would use E-LSPs with as many OAs as I can fit on them. Then I am doing
> > aggregate CSPF and aggregate CAC.
>
>In my opinion there are scenarios in which I want to do aggregate TE in my 
>network, and at the same time I want to perform per-class CSPF and 
>per-class CAC. Let me illustrate this concept through an example. Imagine 
>4 nodes A, B, C and D:
>
>                 +---+
>     +-----------+ C +-----------+
>     |           +---+           |
>   +-+-+                       +-+-+
>--+ A |                       | B +--
>   +-+-+                       +-+-+
>     |           +---+           |
>     +-----------+ D +-----------+
>                 +---+
>
>Each of the four links (AC, AD, CB, DB) can support a total traffic of 
>100Mb/s (up to 50 Mb/s of EF traffic and the remaining amount for BE). Now 
>imagine that at a given moment in time the link occupancy is the following:
>
>         Link AC: EF=20Mb/s, BE=40Mb/s (40Mb/s free, 30Mb/s of which 
> available for EF)
>         Link CB: EF=20Mb/s, BE=40Mb/s (40Mb/s free, 30Mb/s of which 
> available for EF)
>         Link AD: EF=45Mb/s, BE=15Mb/s (40Mb/s free, 5Mb/s of which 
> available for EF)
>         Link DB: EF=45Mb/s, BE=15Mb/s (40Mb/s free, 5Mb/s of which 
> available for EF)
>
>Now imagine that you want to set up an E-LSP from A to B requesting 20Mb/s 
>of total bandwidth (10Mb/s for EF and 10Mb/s for BE). You can route it 
>through C, but you can't do the same through D. This is a case in which I 
>think that per-class CSPF and per-class CAC are useful even in the case of 
>E-LSP.
>In my opinion the service provider should be free to choose between 
>setting up 2 L-LSPs (or two E-LSP carrying a single OA) or setting up just 
>one carrying both classes. In the latter case the standard shouldn't 
>artificialy limit its traffic engineering capabilities. As a pointed in my 
>previous mail, the only piece we have to add in order to support this 
>scenario is the possibility to signal per-PSC bandwidth requirements.
>
>Regards
>Roberto