[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TE Requirements Draft - ELSP
Hi Joel,
what do you exactly mean by "engineering the EF traffic separately from the BE traffic"? If you mean that I have to route/protect/restore etc. EF flows separately from BE flows I agree with you: L-LSP is the best choice. I'm not denying this.
What I state is that even in the case of aggregate TE (i.e. same route and same protection/restoration options for all the classes) it would be useful to have per-class CSPF and per-class CAC. Referring to the example in my previous mail, what do you decide when you have to set up a 10Mb/s E-LSP (50%EF and 50%BE)? Since both available paths (A-C-B and A-D-B) have 40Mb/s of available bandwidth and you don't signal per-PSC bw requirements of the E-LSP, they are equivalent for you. However, as stated in that example, the path through D is not good. Since the ingress LER A hasn't got enough information to realize this, it could choose the path A-D-B; the result would be a total amount of EF traffic equal to 45+10=55Mb/s against the 50Mb/s available, hence either EF traffic dropped in the core or LSP rejected. You can avoid this simply by choosing the path through C, but to do so you have to know the BW requirements per-PSC.
Of course you can also set up two L-LSPs and to admit/route them separately... right, but this means that you double states and ILM in the LSR and signaling for setup/teardown and soft state refresh (in the case of RSVP-TE) across the network. A small service provider with a simple network topology (i.e. quite unmeshed) and a limited set of service classes could be interested in limited Traffic Engineering capabilities (i.e. simple aggregate load balancing). So E-LSP is the best choice for him, why should it be forced to adopt L-LSP? If he uses a very simple CSPF algorithm that routes all classes together (e.g. a shortest path applied on the pruned network), what is the added value of doubling the number of LSPs? This is the point I was trying to outline in my example.
I agree with you and Francois... L-LSP is the best choice in most of the cases, but in my opinion we shouldn't forget that E-LSP exists and could be used in some scenarios. Otherwise, if we limit the E-LSP to those cases in which I do not perform TE at all, my question is: why do I use MPLS in those cases? Without TE and using only SPF, what do I gain by MPLS? A pure diffserv network should be enough, I think. What is the opinion of other people on the list?
Regards
Roberto
> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@stevecrocker.com]
> Sent: Tuesday, November 20, 2001 3:42 AM
> To: TE WG
> Subject: RE: TE Requirements Draft - ELSP
>
>
> [Reformatted to convince the mailer to accept it...]
>
> We already have a way (with two sub-cases) to meet the
> requirement. Fundamentally, if you want to engineer the EF traffic
> separately from the BE traffic (which seems a sensible thing
> to do) then do
> so. Insisting on using shared LSPs but separate advertisements and
> engineering does not seem a noticeable improvement. To quote
> (or mangle a
> quote from) several good people:
> Perfection is achieved when there is nothing left to remove.
>
> To put this differently, if you really are trying to engineer
> the paths
> separately, it seems equally likely that you will get cases where the
> composite LSPs do not take the right path, and you need separate
> ones. Forcing them together strikes me as bad advice to the
> service provider.
>
> IETF experience is that options (particularly very similar but not
> identical options that meet the same goals) are dangerous and
> counter-productive. If we really need this option, there
> ought to be a
> clear reason that is not met by the existing tools.
>
> Thank you,
> Joel M. Halpern
>
> At 06:53 PM 11/19/01 +0100, Roberto Mameli (ERI) wrote:
> >Hi Francois and all,
> >
> >I do not completely agree with you. Please see my comments below.
> >
> > > -----Original Message-----
> > > From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> > > Sent: Monday, November 19, 2001 5:49 PM
> > > To: Choudhury, Sanjaya
> > > Cc: 'Francois Le Faucheur'; Jim Boyle; TE WG
> > > Subject: RE: TE Requirements Draft - ELSP
> > >
> > > - if I want to do aggregate TE in my network, then I
> > > would use E-LSPs with as many OAs as I can fit on them.
> Then I am doing
> > > aggregate CSPF and aggregate CAC.
> >
> >In my opinion there are scenarios in which I want to do
> aggregate TE in my
> >network, and at the same time I want to perform per-class CSPF and
> >per-class CAC. Let me illustrate this concept through an
> example. Imagine
> >4 nodes A, B, C and D:
> >
> > +---+
> > +-----------+ C +-----------+
> > | +---+ |
> > +-+-+ +-+-+
> >--+ A | | B +--
> > +-+-+ +-+-+
> > | +---+ |
> > +-----------+ D +-----------+
> > +---+
> >
> >Each of the four links (AC, AD, CB, DB) can support a total
> traffic of
> >100Mb/s (up to 50 Mb/s of EF traffic and the remaining
> amount for BE). Now
> >imagine that at a given moment in time the link occupancy is
> the following:
> >
> > Link AC: EF=20Mb/s, BE=40Mb/s (40Mb/s free, 30Mb/s of which
> > available for EF)
> > Link CB: EF=20Mb/s, BE=40Mb/s (40Mb/s free, 30Mb/s of which
> > available for EF)
> > Link AD: EF=45Mb/s, BE=15Mb/s (40Mb/s free, 5Mb/s of which
> > available for EF)
> > Link DB: EF=45Mb/s, BE=15Mb/s (40Mb/s free, 5Mb/s of which
> > available for EF)
> >
> >Now imagine that you want to set up an E-LSP from A to B
> requesting 20Mb/s
> >of total bandwidth (10Mb/s for EF and 10Mb/s for BE). You
> can route it
> >through C, but you can't do the same through D. This is a
> case in which I
> >think that per-class CSPF and per-class CAC are useful even
> in the case of
> >E-LSP.
> >In my opinion the service provider should be free to choose between
> >setting up 2 L-LSPs (or two E-LSP carrying a single OA) or
> setting up just
> >one carrying both classes. In the latter case the standard shouldn't
> >artificialy limit its traffic engineering capabilities. As a
> pointed in my
> >previous mail, the only piece we have to add in order to
> support this
> >scenario is the possibility to signal per-PSC bandwidth requirements.
> >
> >Regards
> >Roberto
>
>