Subject: could we agree on this ? Fwd: RE: TE Requirements Draft - ELSP

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 30 Nov 2001 15:16:26 +0100

Shahram and all,

>>From: Shahram Davari <[email-masked]>
>>To: "'Francois Le Faucheur'" <[email-masked]>, [email-masked]
>>Cc: [email-masked]
>>Subject: RE: TE Requirements Draft - ELSP
>>Date: Tue, 27 Nov 2001 10:38:36 -0800
>>X-Mailer: Internet Mail Service (5.5.2653.19)
>>Sender: [email-masked]
>>
>>Francois,
>>
>>I think what Neil was asking is none of these. He was asking for multiple 
>>OA over E-LSP, each with their own BW, but all of them with the same 
>>preemption, affinity, etc. Basically this is what is required for VPN 
>>support. The 3rd option that you mentioned is practically very 
>>complicated, since it requires dynamic aggregation and splitting of OAs.

Here's an updated analysis of the thread:

In a nutshell, there seem to be actually 4 options for use of E-LSPs (I 
think we were talking about different things for option 2 so I propose to 
break it up in two cases) and I'm hoping we may already be able to agree on 
how to deal with three of those. Let's try:

1) using E-LSPs with traffic from a single OA:
==============================================
A number of people have agreed with the proposal to allow support for this 
in the next version of the REQTS draft. I haven't heard anyone disagreeing. 
So I consider this one closed. Agreed?

3) using E-LSPs with traffic from multiple OAs each with their own SPF
======================================================================
This is the option I proposed to keep out of the Reqts draft for now. This 
is also the option you described above as "practically very complicated, 
since it requires dynamic aggregation and splitting of OAs."  Can we agree 
to keep this out of REQTS draft?

2) using E-LSPs with traffic from multiple OAs but using single CSPF
=====================================================================
I think we actually need to break this up in 2 cases:

2a) using E-LSPs with traffic from multiple OAs but using single CSPF and 
SINGLE bandwidth
==========================================================================================
This is for Jim's scenario. ie I want to transport voice_payload + 
voice_sig on the same E-LSP AND I know the relative proportion of each 
(e.g. I know that on each "Voice" Traffic Trunk there is always 80% of 
traffic being voice_payload and 20% of voice_signaling). I want to do CSPF 
for each of these Voice Traffic Trunk and I use a single bandwidth value 
which repesents the sum of voice_payload+voice-sig. Again, this can be 
achieved without any extension to signaling protocols and does not create 
change to the current DSTE model.
I proposed to allow support for this in the REQTS draft. I understand you 
would also like to be able to signal multiple bandwidth for situations 
where the ratio across voice_payload and voice_sig is not constant, but can 
you agree that when it is constant the above scenario is useful?

2b) using E-LSPs with traffic from multiple OAs but using single CSPF and 
MULTIPLE bandwidth
=============================================================================================
This is for the case where multiple OAs have their own bandwidth 
requirements , but have the same affinities and same preemtion and same 
restoration AND you do NOT want to transport them on their own L-LSPs.
This is the scenario to which most of the discussions we've had relate.

Before we discuss 2b) any further I'd like to see whether we can first 
agree on how to deal with 1), 3) and 2a) because I have the impression we 
may be able to.

Could you agree to:
         - allow 1) ?
         - keep 3) out for now ?
         - allow 2b) ?

Thanks for your views

Francois

>>Yours,
>>-Shahram
>>
>> > -----Original Message-----
>> > From: Francois Le Faucheur [mailto:[email-masked]]
>> > Sent: Tuesday, November 27, 2001 11:51 AM
>> > To: [email-masked]
>> > Cc: [email-masked]; [email-masked]
>> > Subject: RE: TE Requirements Draft - ELSP
>> >
>> >
>> > 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
>> > _________________________________________________________
>> >
>> >

_________________________________________________________
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: Fri, 30 Nov 2001 11:26:02 -0500

Francois,

One key item of note. In an earlier email, you had stated that 
Nabil/Sudhakar asked for option (3). This is not quite accurate.

We had argued for the ability to signal BW for multiple OAs on 
a single LSP. In addition, we argued for the ability to advertise
BW for multiple OAs (classes) in the IGP. How the CSPF is done
is a proprietary matter. It is not governed by the standards!

Best,
Nabil

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

---

From: Nabil Seddigh <[email-masked]>
Date: Fri, 30 Nov 2001 11:31:59 -0500

Francois

Your attempt to summarize the issues is good. However, there is an 
important point to be made. To do TE, one needs:

a)   IGP to advertise BW
b)  CSPF algorithm to select path
c) Signalling protocol to signal LSP with BW, pre-emption priority etc

This WG can standardize mechanisms to support (a) and (c).
Hoewver, (ii) is entirely proprietary. The algorithms and schemes
are vendor specific. Right? 

I think there is current agreement that the IGP can advertise per
class BW (akin to per-OA). Thus the open issue relates to (c)
In this regard, I would suggest that your options are actually:

  i) Using E-LSPs with traffic from a single OA
 ii) Using E-LSPs with traffic from multiple OAs with single BW
 iii) Using E-LSPs with traffic from multiple OAs with multiple BW
  iv) Using L-LSP

There seems to be prior agreement that options (i) and (iv) are
required. The open questions seem to be whether or not (ii)
and (iii) are required.

Kind Regards
Nabil