ITPRC.COM
ITPRC News - September 2001
Search The ITPRC:
Career Management
Book Sites
Job Databases
Job Boards
Publications
Trade Shows
Training and Certification

Technologies
Physical
Data Link
Content Networking
Directories

IP Routing
OSs
QoS, Cobit

SANs
TCP/IP
TCP/IP FAQ
Voice & Data
VPNs & Encryption
Wireless

Operations
ISP Resources
Network Management
Network Security

Other
Guides
Humor

Link of the Week
Miscellaneous
Newsletter Archive

ITPRC NEWS - September 2001 - http://www.itprc.com/

The Latest Spectator Sport - MPLS Bashing
By Irwin Lazar

A recent cover story in Network World entitled ďExperts Call MPLS Bad for ĎNetĒ [http://www.nwfusion.com/news/2001/0806mpls.html] has spurned considerable discussion over the merits of this emerging technology.  Similar stories in Interactive Week and on the Lightreading.com web site have also been highly critical of MPLS.  The arguments raised against MPLS seem to center around a few specific concerns: that MPLS isnít secure, that MPLS isnít necessary, and that MPLS simply recreates what is already available via ATM.  Letís take a look at each of these points.

MPLS Isnít Secure:
The security argument against MPLS is often heard when MPLS-VPN services are compared with IP-VPN services based on a secure encryption protocol such as IPsec.  The reasoning is that since MPLS carries unencrypted IP payloads, it is inherently insecure.  The problem with this argument is that it is an apples-to-oranges comparison.  The fact of the matter is that MPLS and IPsec are complementary, not competing technologies.  MPLS, as a VPN technology, provides the same level of security as other virtual circuit alternatives such as ATM or Frame Relay.  All three switch traffic outside of the IP layer, all three carry unencrypted payloads, and all three carry the same security risk (as noted by a recent Meircom report).  If security of transmissions is a concern, nothing prohibits running IPsec over an MPLS-VPN. 

MPLS Isnít Necessary:
The security argument leads us into our next criticism of MPLS, that it isnít necessary because IPsec VPNs are available today.  This argument typically states that MPLS introduces additional network complexity, and that MPLS-VPNs require core routers to be aware of additional VPN information.  Of all the MPLS arguments, this one is most easy to refute.  

First, as previously stated, MPLS-VPN services are complementary, not a competitor to IPsec VPNs.  IPsec VPNs typically run over the public Internet, where there are no performance guarantees.  MPLS-VPN services typically run over a carriersí private IP backbone, where service level guarantees and various classes of service can be provided.  MPLS-VPN services across multiple carrier backbones are typically only provided when providers create service level agreements and/or partnerships to carry each otherís traffic.

It must also be noted that like IPsec VPNs, MPLS-VPN services only require configuration at the end points.  Only the end points must maintain VPN state information.  Once a traffic leaves an end-point, it is encapsulated into a label switch path.  The core switch-routers do not need to maintain VPN information.  I repeat, the core switch-routers do not need to maintain VPN information.  I canít repeat this statement often enough (nor can I repeat the statement that MPLS-VPNs based on RFC-2547 doesnít require BGP on the CPE often enough, but thatís another article).  Given that VPN awareness is confined to the end-points, MPLS-VPNs are no more complex to deploy and manage than IPsec VPNs, and MPLS-VPNs donít require complex key or certificate management.

MPLS Recreates ATM:
This argument is probably the most true of all three criticisms cited in this article.  MPLS, in many respects, does indeed recreate ATM.  If public networks had migrated completely to ATM, and ATM was the only networking technology being deployed in the future, we might not have a need for MPLS.  But, the fact of the matter is that many different kinds of public transport networks exist: ATM, Ethernet, Frame Relay, SONET, and even point-to-point DWDM.  The one constant over all of these physical and data link technologies is that they are likely going to be carrying predominantly IP traffic.  We all know the inefficiencies of carrying IP within ATM due to the cell tax.  Given that future network transport demands are based on carrying larger and larger amounts of IP traffic, it makes sense for carriers to deploy a physical infrastructure that is optimized for IP.  ATM is not that infrastructure, and especially not in the core where ATM speeds of OC-12 and greater have been slow to materialize. 

Therefore, we can easily look to a future (or perhaps a present) where a large variety of physical transport technologies interconnect to carry IP.   With that reality, doesnít it make sense for carriers to deploy a VPN technology that allows tunnels to be created on top of this IP layer, regardless of the physical infrastructure?  Doesnít it make sense for carriers to deploy a VPN technology that can connect an office in NY that accesses the carrier PoP via Ethernet, with an office in LA that connects via DSL or Frame Relay?  Short of building one ubiquitous Layer 2 infrastructure (which was the early dream of ATM proponents), is there any feasible alternative ďotherĒ than MPLS? 

And after all, Isnít that the real question? 

..............................
Irwin Lazar is a Senior Consultant for The Burton Group where he focuses on strategic planning and network architecture for Fortune 500 enterprises as well as large service providers. He is the conference director for MPLScon and runs The MPLS Resource Center http://www.mplsrc.com  and The Information Technology Professional's Resource Center - http://www.itprc.com

Please send any comments about this article to ilazar@tbg.com ============================================================

All Content Of This Site Is Copyright 2000-2004 - ITPRC.COM

 
Subscribe To Our Free IT Newsletter