[MPLS-OPS]: Re: [e2e] Re: [ippm] [Fwd: State of MPLS deployments
bagula at cs.sun.ac.za
Mon Oct 7 00:23:54 PDT 2002
On Fri, 4 Oct 2002, Ajay Simha wrote:
> 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: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 give 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.
Thanks Ajay. This sheds some light on the topic.
> >AB:BA. Bagula.
> >AB:On Thu, 3 Oct 2002, Robert Raszuk wrote:
> >AB:> Hi Randy,
> >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:> R.
> >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:> 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:The MPLS-OPS Mailing List
> >AB:Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
> >AB:Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
More information about the end2end-interest