[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
could we agree on this ? Fwd: RE: TE Requirements Draft - ELSP
Shahram and all,
>>From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
>>To: "'Francois Le Faucheur'" <flefauch@cisco.com>, neil.2.harrison@bt.com
>>Cc: te-wg@ops.ietf.org
>>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: owner-te-wg@ops.ietf.org
>>
>>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:flefauch@cisco.com]
>> > Sent: Tuesday, November 27, 2001 11:51 AM
>> > To: neil.2.harrison@bt.com
>> > Cc: flefauch@cisco.com; te-wg@ops.ietf.org
>> > Subject: RE: TE Requirements Draft - ELSP
>> >
>> >
>> > Hi,
>> >
>> > At 12:51 22/11/2001 +0000, neil.2.harrison@bt.com 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: flefauch@cisco.com
>> > _________________________________________________________
>> > 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: flefauch@cisco.com
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410 Biot - Sophia Antipolis
FRANCE
_________________________________________________________