[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TE Requirements Draft - ELSP
Hi Joel and all,
let me try again to explain my point of view. I have no reasons to prefer E-LSP with respect to L-LSP (and vice versa). I just observe that both exist and, probably, there is some reason justifying them.
It is very clear to me that in most scenarios L-LSP (or E-LSP carrying a single OA) are the best solution, since they offer advanced per-class TE capabilities and finer granularity per class control. I'm not discussing this. However my question is again: in which situation E-LSP (carrying several OAs) is preferable? Quoting Francois' previous mail:
>> - if I don't want to do TE in my network, then I would use E-LSPs with as many OAs as I can fit on >> them.
>> - 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.
So, again, if I don't want to do TE in my network, I have probably no reasons to use MPLS at all. A pure DiffServ network is good in that case (please correct me if I'm wrong).
However, if I want to do aggregate TE in my network, I wonder what is the exact meaning of aggregate TE. You say that the "usual assumptions that allows aggregate TE and per class CAC is where the allocation of intra-LSP resources is up to the LSP ingress". I think this is very limiting and I wouldn't call it aggregate TE... it's quite similar to the situation of a pre-configured DiffServ network. Instead appendix A3 of draft-ietf-mpls-diff-ext-09.txt says:
A Service Provider running 8 (or fewer) BAs over MPLS, performing
aggregate Traffic Engineering (i.e. performing a single common path
selection for all BAs), using aggregate MPLS protection (i.e.
restoring service to all PSCs jointly) and ..... etc.
So, it seems to me that aggregate TE simply means that I choose a single path supporting all BAs, with the same protection/restoration options. This does not automatically preclude that CSPF and CAC require per-PSC bandwidth information as an input. I simply give N bandwidth requirements (one for each of the N classes) to the CSPF algorithm, and it gives me back a SINGLE path capable of carrying all the BAs. If my CSPF would run based only on the E-LSP aggregate bandwidth I would not be able to choose between two different paths with the same total occupancy... see again my previous example, where each link is preconfigured to 50% in all the routers (not reserved, simply preconfigured). In that example I do NOT make aggregate reservation... I have preconfigured BW in every node and simply need some additional information to choose the best way to route the new LSP.
However, my point is that I don't want to force the SP to use E-LSP. I just want to say that, since E-LSP exists, a provider could be interested to use it (for whatever reason). If E-LSP cannot be used for nothing more than pure DiffServ, than there is no reason to have E-LSP. Just set up N L-LSP instead of a single one carrying N OAs. But if we think that E-LSP are really useful we cannot bias the standards towards a specific solution.
Hope this clarify my view.
Best regards
Roberto
> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@stevecrocker.com]
> Sent: Tuesday, November 20, 2001 1:32 PM
> To: Roberto Mameli (ERI); TE WG
> Subject: 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
> > >
> > >
>