[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TE Requirements Draft - ELSP
Let me try to describe what I think your after, and how it can work with
the current tools.
You are saying that you want to be able to do per-class CAC (probably
necessary), and aggregated E-LSPs (desirable). You then conclude that you
need per link per class resource information.
If you want to be able to do per-link allocation between EF and BE, of
course you need per-link per-class resource information. In that case, it
makes sense to do per-class LSPs.
If you are trying to do aggregate reservation, it must be because
aggregation makes some sense. In your example, not only do you have
varying link utilization per class (a requirement to get the problem you
suggest), but the links somehow know this. In order for the links to know
the EF and BE distributions, the reservations on the links must be per
class. But you just said that you are doing TE in aggregate! Where did
the link per class resource information come from? Did the TE LSP
reservation carry the individual resource requirements? THen it was really
two LSP setups, not one.
The usual assumption that allows aggregate TE and per-class CAC is where
the allocation of intra-LSP resources is up to the LSP ingress. In that
case, for each LSP that it sets up, the ingree reserves a total
bandwidth. As a simple case, if EVERY ingress allows only 15% of EACH LSP
to be used for EF, then by definition (assuming no overbooking) no router
will see more than 15% EF anywhere. If 15% is the supportable level of EF
traffic with the guarantees you want to make, then you have achieved your
goal. At ingress, you make sure that the EF traffic you deliver into the
network is less than 15% of each LSP you send it over. (Do this by
policing, CAC< or some other mechanism as you choose.)
Yours,
Joel M. Halpern
PS: Sorry I wandered a bit. I am trying to find different views to
exaplain what you might be after, since just there is presumably some real
world problem you are trying to address.
At 10:25 AM 11/20/01 +0100, Roberto Mameli (ERI) wrote:
>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
> >
> >