MPLS VPNs or not?

Wed Aug 8 07:30:53 UTC 2001

Daniel,

> The scary thing is that the "speed" of MPLS-based networks is taken as
> gospel by an alarming number of engineers, mainly those who have come out of
> the large telco's (i.e. ILECs), and are still kind of mad that ATM didn't
> work out. These folks are more or less alarmed by IP, and desperately seek a
> more deterministic, switch-based model of data transmission for the Internet
> as a whole. The fact that there is no practical, real-world difference in
> forwarding speed between straight IP, and IP over MPLS is generally
> explained away by these guys in a fairly elaborate handwaving exercise. At
> least one major hardware vendor is not helping this, with some of their
> engineers convincing major customers that conventional IP routing is bad,
> and that anything MPLS is good. While I agree that MPLS has it's uses - i.e.
> TE as an exception handling mechanism for outages, and L2VPN technology as a
> FR/ATM replacement, some folks need to approach the technology with
> additional caution, and not blindly embrace it as a panacea. As the internet
> engineering community evolves, learning from things like ATM, becomes quite
> important.
> 

Too true! Whats scary is that product "managers" believe the hype, and
you get into discussions about how MPLS can enable "application based
QoS" because some sales "engineer" [WTF is that anyway?] at a vendor 
conference has waffled on about it and how well it works.
What isn't provided at these conferences are the realities in
deploying it, or any real life examples of an application, and also
finding some dumg idiot thats willing to pay for it when he can
buy something else [ATM/FR/SDH/PDH] at fraction of the price isn't
clear either. Oh and that the router supports these features in:
3.fixed3bugs.added14others.4.hohoyoureatotalnutterifyourunthiscode.1
and that the management system will be able to manage these features
in q4 of 2010 which , "but no we won't commit to that" and isn't our CLI
wonderful.

Some of the VPN/VRF functionality clearly isn't deployable in a scalable
manner [atleast my definition of scalable], I think one of the solutions
to scaling is to deploy multiple sets of route-reflectors to manage
routing updates for different services. One set for Internet, one for high
level service, and one for low etc. That, to me, isn't the definition of
scaling and the minute you get a customer who wants to cross the boundaries
of this setup you are screwed.  

The other thing that is worrying is how many telco dinosaurs have
come out of their hiding places claiming to be gurus on all things
IP and MPLS because to them it looks like a telephone switch. These
people will cause you to lose hair - either trying to get a word in
edgewise or trying to fix the abortive "designs and solutions" that
they have "engineered". Be afraid!

Regards,
Neil.