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

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

Hi Shai/all,

please see my comments below...

> -----Original Message-----
> From: Shai Herzog [mailto:sherzog@hyperchip.com]
> Sent: Thursday, December 06, 2001 3:23 PM
> To: 'Sudhakar Ganti'; 'te-wg@ops.ietf.org'
> Subject: RE: What we disagree on RE: TE Requirements Draft-ELSP
> 
> 
> 1. A fixed ratio around the network? How does that relate to
>    End-to-End tunnel BW? (I hope you at least recognize that).

I perfectly agree with your observation. Even if we preconfigure network nodes according to a fixed ratio (let's say 20%EF-80%BE), we are not sure that the limitation of EF ingress traffic to 20% is enough to avoid EF congestion in internal nodes. This is a well known problem for DiffServ people, and is related to how traffic aggregates/disaggregates into the network.

>    Saying AF1 to AF2 is 1/10 in BW is no different than saying
>    that all AF1 in the network get X BW, and AF2 get Y BW. Both
>    have nothing to do with Traffic Engineering because the provide
>    NO per tunnel QoS guarantees.

Again I perfectly agree with you, and I also agree with the observation you made in your previous mail, concerning the usefulness of E-LSP for TE purposes. You explicitly stated:

	So, we're left with only the case of an E-LSP with a single OA as a
	meaningfull TE approach. (which sounds awfully close if not identical to
	L-LSP).

This is exactly my opinion. My original concern is that E-LSP carrying multiple OAs according to the current standard is nothing (or very little) more than pure DiffServ. It's not really a form of Traffic Engineering.

Now the choice is twofold:

(1) drop E/L-LSP as you propose and use just one single type of LSP (let's call it DS LSP as you do)
(2) keep the original distinction between E-LSP and L-LSP, but add the E-LSP with some limited TE capabilities

Option 1) is very radical. It requires a dramatic change in the current MPLS-DIFF architecture. Option 2), instead, is quite soft from this point of view, even if implies some minor protocol extensions. Anyway, following Nabil's mail I'd like to outline that this extensions are OPTIONAL. If a SP doesn't want to exploit these capabilities (i.e. if it uses L-LSP, single OA E-LSP, multiple OA E-LSP with a single bw parameter, atc.), it does'nt have to do nothing more than what is currently requested by the DS-TE draft.

Regards
Roberto