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
|