[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TE Requirements Draft - ELSP
At 13:38 16/11/2001 -0500, Jim Boyle wrote:
>Francois - if your question is:
>
>-----------------------
>Would service providers wish to potentially send more than one, OA down an
>E-LSP, which makes use of class-type specific routing information?
>-----------------------
>
>The answer is yes.
>
>Picking on poor voice, one OA might be signalling traffic, one might be
>VoIP data. They might go into different queues. They might not need to
>be on seperate LSPs.
I am still struggling to picture a whole deployment scenario:
in this example would you assume that :
(i) a path has been computed separately for voice sig and voice
flows (each with a separate bw requirements and potential differnet
bandwidth constrainta/CT). In that case, I feel that it woudl be simpler to
just put those on differnet LSPs. no?
(ii) a path has been computed for one of the two , say voice-flows
(based on the voice-flow bandwidth requirements and using the voice-flow
bandwidth constraint/CT). In that case, why woudl you want to send the
voice sig on that tunnel? why not sent it on its SPF? sending voice-sig on
the tunnel routed for voice flow will just result in potentially sending on
a longer-than-SPF path which you have no idea whether it is actually better
or worse than the SPF-path considreing teh voice-sig resources (which are
independent from teh voice flow resources). In other words, if I only do
CSPF for one OA, I woudl personnaly be inclined to send the other OA on an
SPF-LSP rather than on that CSPF LSP because it has just as many chances of
making it worse than making it better. no?
Thanks
Francois
>The LSP might draw upon resources of a non-default
>class-type.
>
>Hope that's not too fancy ;)
>
>Jim
>
>On Fri, 16 Nov 2001, Francois Le Faucheur wrote:
>
> > At 10:04 16/11/2001 -0500, Nabil Seddigh wrote:
> > >I thought I should get this comment in before the -02 version
> > >of the Requirements draft emerges.
> >
> > just in time...
> >
> > >Hopefully the authors will
> > >consider the following suggestion:
> > >
> > >- I think it is useful to put an explicit requirement that the TE
> > > solutions need to support both E-LSP and L-LSP. The way the
> > > draft reads at the moment, it does not come through clearly.
> > > Most of the examples and wording would lead one to believe that
> > > the DS-TE solutions should only focus on L-LSP.
> >
> > That's because the requirements indeed assumes that DSTE will be deployed
> > using L-LSPs (or E-LSPs but on which traffic from a single OA is carried).
> > soon-to-be-released-02 already has text clarifying this.
> > When deploying DS-TE, the SPs I spoke to wanted not only to do per-class
> > admission control but also per-class routing, which normally requires use
> > of L-LSPs (or E-LSPs transporting a single OA).
> >
> > Is allowing operations of DS-TE over E-LSPs which transport a single OA
> > what you're after (in which case it's already there)?
> >
> > Or are you suggesting operations of DS-TE over E-LSPs which transport
> > multiple OAs?
> > In that case, what are the Service Provider requesting this?
> >
> > Could these SPs clarify whether:
> > - they would use this to do per-class admission control but not
> > do per-class routing (would it not be a pity to deploy all this
> > sophistication and have voice not being able to take its shortest path
> > simply because there is no more resources for data on a link)?
> > - they expect the routers to do fancy things like
> > dynamic/on-the-fly mapping of OAs on various LSPs : compute path for
> > differnet OAs separately and then if they happen to be the same at one
> > point in time push them onto the same LSP? then what happens if later on,
> > one OA gets preempted and not the other one: remap one OA on another LSP
> > with some other OAs?
> >
> > Thanks
> >
> > Francois
> >
> >
> > >Best
> > >Nabil Seddigh
> > >nseddigh@tropicnetworks.com
> >
> > _________________________________________________________
> > 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
_________________________________________________________