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 ============================================================