[MPLS-OPS]: Re: [e2e] Re: [ippm] [Fwd: State of MPLS deployments today]

[Ajay Simha]

On Fri, 4 Oct 2002, Antoine Bagula wrote:

>AB:I have the impression that Robert's type of answer is typical on this list
>AB:when pros and cons MPLS is concerned. Thanks to Randy and Bob for their
>AB:interventions which i hope will help us avoid agressive answers on the
>AB:list in the future. I also think that as far as MPLS efficiency, utility
>AB:or whatever people should call as synonym of efficiency, several questions stand
>AB:unanswered:
>AB:1) Can people express their opinion on the list concerning limitations of MPLS ?
>AB:2) Can those who have solutions to these limitations also propose
>AB:these solutions ?
>AB:3) Did someone on the list gave an answer to the concern of professor Kave
>AB::  what is the effect of traffic engineering on network performance?

Sorry... this thread *has* lost focus (at least for me). I'll attempt to
answer the last question (3)....

My experience has been with MPLS-TE (opposed to general TE).

For the sake of this discussion let's agree that the definitions of "large SP"
as those who have say 30 to 50 POPs.

Some of the SPs have what we call *strategic* TE which involves a
full mesh of TE tunnels (either in the core or edge). The largest network that
we have seen today with MPLS-TE involved about 10k tunnels in the network.

Some of the testing we did in our labs showed:

600 headends, 10,000 midpoints/tail scaled pretty well.

So... going back to a network with 10k (This number comes from having 100
routers in a full mesh), it means even if this network grew 6 times it would
be within the scaling limits.

Now moving forward in time... There have been optimizations within RSVP (Sorry
cannot talk about CR-LDP because I have no experience in that) and routers
have gotten bigger and better and these scaling numbers increase.

For the foreseeable future I think talking 100 routers in mesh is a good number
to consider as a *large* network. So I'd say it is fair to conclude that TE
scales pretty well in a practical/real network.

Now if the question was geared more towards forwarding performance in a TE
environment, I'd say that in an MPLS forwarding core, it makes no difference if
the labels were exchanged due to RSVP or LDP it does not matter when a packet
needs be switched. The LFIB is consulted and the packet is forwarded much in
the same way as it is done in Frame Relay or ATM switch.

I hope this answers at least some of the questions/issues.

-ajay


>AB:
>AB:BA. Bagula.
>AB:
>AB:On Thu, 3 Oct 2002, Robert Raszuk wrote:
>AB:
>AB:> Hi Randy,
>AB:>
>AB:> As far as the clue part I would recommed to wait for VPRN presentation
>AB:> to go public at next nanog so everybody can judge who is clufull or
>AB:> clueless reg MPLS applications especially 2547bin :-).
>AB:>
>AB:> R.
>AB:>
>AB:> > Randy Bush wrote:
>AB:> >
>AB:> > >> I was saying that today we don't have yet (or at least I have not heard of)
>AB:> > >> a full MPLS large network. I was not meaning that nobody is using MPLS in
>AB:> > >> portion of his network.
>AB:> > > It is quite known that university professors are pretty much out of
>AB:> > > touch with real networks and reality.
>AB:> >
>AB:> > as opposed to out of touch with manners or clue?
>AB:> >
>AB:> > _______________________________________________
>AB:> > ippm mailing list
>AB:> > ippm at advanced.org
>AB:> > http://mailhost.advanced.org/mailman/listinfo/ippm
>AB:>
>AB:> -------
>AB:> The MPLS-OPS Mailing List
>AB:> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>AB:> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>AB:>
>AB:
>AB:-------
>AB:The MPLS-OPS Mailing List
>AB:Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>AB:Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>AB: