RE: TE Requirements Draft - ELSP

[neil.2.harrison@bt.com]

Thanks Shahram,

That is exactly correct.  I am postulating a potential requirement to
emulate what can be done on today's L2 VPN solutions, ie for those customers
who demand measurable and disjoint availability/QoS SLAs and/or who might
perhaps want to run their own DS regime over some leased 'LSP BW pipe'.  In
the orginal mail (snipped here) I gave an example of the difficulties one
faces if using LDP with like-DS-class merging across VPNs, ie the fact that
there is no relationship between survivability and up-state QoS treatment at
the packet level (both within the same and across different DS classes).  To
put this a different way, what I am saying is that it might be useful if we
could provide a network service at the 'LSP' level and not the 'packet'
level.  It is not clear to me yet how such VPN solutions can be provided
with MPLS....and maybe they can't, though doing XoverMPLS (eg X = FR,
ethernet, ATM) is a very similar requirement and maybe the (only possible)
answer lies within the work of the PWE3 group?

My concern is if we can't offer this type of network service on MPLS then it
seems we may well be forced to continue running parallel FR/ATM/TDM
platforms.  And I was therefore suggesting that maybe E-LSPs could possibly
offer some form of trad L2 emulation.....but maybe they can't if the focus
is purely on trying to get some unified view, and 'treatment', only at the
(DS) packet level?

regards, Neil

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: 27 November 2001 18:39
> To: 'Francois Le Faucheur'; neil.2.harrison@bt.com
> Cc: te-wg@ops.ietf.org
> Subject: RE: TE Requirements Draft - ELSP
> 
> 
> 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.
> 
> 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
> > _________________________________________________________ 
> > 
> > 
>