Subject: RE: TE Requirements Draft - ELSP

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 27 Nov 2001 17:50:36 +0100

Hi,

At 12:51 22/11/2001 +0000, [email-masked] wrote:
> >
> > 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)?
>NH=> Effectively yes.  As I tried to point out previously, there is no
>relationship between an applications up-state QoS requirements (ie in DS
><clip>

In the hope of progressing towards some agreement, here's an updated 
analysis of the thread + corresponding proposal:

There are (at least) three "ways" E-LSPs may potentially be used for DS-TE :

1) using E-LSPs with traffic from a single OA:
==============================================
This option is already explicitely allowed in the recently posted REQTS draft.
I suggest that this stays so, since everybody's happy with that.

2) using E-LSPs with traffic from multiple OAs but using single CSPF
=====================================================================
This option is not allowed in recently posted REQTS draft.
This option is necessary to:
         - address Jim's scenario
         - address Roberto's scenario
         - address Neil's scenario
This option would not create any real changes to the current DS-TE model 
and entails NO protocol extensions (ie it comes for free complexity-wise)
I suggest that the REQTS draft be changed to allow this option.

3) using E-LSPs with traffic from multiple OAs each with their own SPF
======================================================================
This is not allowed in recently posted REQTS draft.
As Nabil/Sudhakar indicated, it is conceivable that some Service Providers 
might want to do that one day.
But this require departure from the current DS-TE model and entails 
protocol extensions.
I suggest we keep this option on the table for discussion for now but don't 
include it in the REQTS draft until we have established that a body of SPs 
actually want to do this and how it would actually be used (would we need 
just multiple bandwidth or also multiple affinity, multiple preemption,...).
This would allow us to develop a faster simpler DSTE solution that 
addresses what we know SPs want to do today.
We can always add this option at any time later when deemed useful and do 
the corresponding work then.

Looking forward to hearing thoughts on this analysis/suggestion.

Francois

_________________________________________________________
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: "Sudhakar Ganti" <[email-masked]>
Date: Tue, 27 Nov 2001 16:21:40 -0500

Francois,

> 3) using E-LSPs with traffic from multiple OAs each with their own SPF

First, I don't see a need to do per-OA SPF. Since it is a
single E-LSP carrying multiple-OAs, all of them are carried
on the same path. Therefore, the way I see the
SPF works is to take all the bandwidth parameters of OAs and come up
with a path that satisfies best the given constaints and optimization
criteria. The path computation may be a little involved. But this
is proprietary implementaion and standards need not specify it.
However, available bandwidth per-OA (or class) need to be
propagated which other OSPF drafts talked about.

Second point is that, when multiple OAs are carried on E-LSP, there
is no need to define multiple pre-emption attributes. The
pre-emption definitions apply to the whole LSP (and so to all the
OAs together) and not to each traffic class separately.
In fact, if we do multiple OA everything, what would
be the difference between multiple L-LSPs and one E-LSP carrying
multiple OAs?

So, other than extra per-OA signaling needed to account for proper
bandwidth accounting, there is no significant departure from the
current DS-TE model.

-Sudhakar

---

From: Biswajit Nandy <[email-masked]>
Date: Tue, 27 Nov 2001 17:13:19 -0500

Francois Le Faucheur wrote:

> =====================================================

Neither Jim, nor Neils's scenario can be addressed without protocol extensions.
I am afraid, you have jumped to some conclusion. The BIG assumtion to address
Jim's scenario is, the ratio of voice signalling and data is known. I feel that,
it
may be known for some applications but not known for other applications.
Neil's scenario has been nicely articulated by Shahram and it is clear that it
cannot be addressed with current DSTE solution.

> the corresponding work then.

I dont see, how a speedy deployment will get hindered by including ELSP
based solution in DSTE REQT document. As Nabil stated, in his earlier mail,
not everything is MUST.

We have tried to capture some of the discussion in our updated version of ELSP
proposal. This was submitted on Wednesday and should be in archive soon.
In the mean time, you can get it from
http://www3.sympatico.ca/b_nandy/draft-ganti-mpls-diffserv-elsp-01.txt

Regards.

++biswajit