Slashdot Mirror
IETF Debates On: MPLS Is Bad
A reader writes "MPLS, or Multi-protocol Label Switching, seems to be a popular choice for router vendors nowadays until two AT&T researchers argue it differently. They "say MPLS create serious network management challenges for Internet backbone providers." "Even more dire are their warnings about potential security and privacy problems for companies that deploy MPLS-based VPNs." This issue will be discussed on an IETF meeting held this week in London. More details here ." Related to the IETF [?] , this submission came in: The Internet Engineering Task Force (IETF)
is now meeting in London for
IETF-51.
You can watch
multicast sessions. "
QOS is not only about "Resource Optimization" but also about "Traffic Parameters". MPLS does explicit routing: CR-LDP and TE-RSVP- both have supporters and otherwise- by deployinge either of them it performs well on both accounts. I think that from TE point of view more than a technological advantage it offers an excellent business case.. think in terms of Fixed and Operational costs. :)
Anyways prioritization is the name of the game. Also known as might is right. From the Jungle to the OS the rule is valid so whats wrong with MPLS screwing this or that: should my video streams (Hidden Dragon Crouching Tiger) compete with your icons?
You will agree that MPLS performs "atleast" what other relevant technologies have achieved in past: IBM'S Aris, or Toshiba's Packet Switching etc. It does appear to be a the logical next step in the evolution of packet forwarding. It is a standard independant of manufacturers. Even it is biased, you cant argue with the sense of buyers. Market forces ultimately decide the technology S-Curve.
It has problems Scalability , Security, etc but alteast the things are moving in the right direction.
For purely administrative reasons it falls short of offering an end-to-end QOS . So the relevance of argument, by some, that it maynot become the "internet" technology is perhaps valid.
Voltaire: God is dead.
God: Voltaire is dead!
As a user of a 300+ site MPLS VPN ompressions are generally very good. Apart from a few bugs where MPLS tags are ocasionally lost.
The alternative of a 300 site IPSEC Tunnel VPN with full mesh connectivity would be a lot harder to manage.
slashnik
This is a "Good Thing" for several reasons. For one thing, it's quicker, as IP addresses are variable length, whereas MPLS labels are fixed. It also allows a lot more granular traffic control and shaping. Also, you can encapsulate just about anything inside MPLS, not just IP. And you can do QoS, CoS, VPN and lots of other stuff.
This is a VERY simplified version of what MPLS is and does. For more information try the following:
And, no offense, but a "bit" misleading... For instance IP addresses are not variable length...
As for being a "good thing", techonologies are very seldom good or bad... they have pluses and minus, costs and benefits... the irritating thing about MPLS is that every marketing department in the networking world sudently started to claim that it was the cure for "world hunger"... it isn't.
Immediatly as you deploy mpls in a network you are deploying an entire new set of control protocols and having 2 ways traffic can flow intead of just 1. It becomes exponentially harder to diagnose... contrary to what the original poster mentioned, mpls LSPs (tunnels) are not usually manually created (if they are they will not automatically reroute in case of failure).
This is not to say that there are not ocasions where mpls might not be a cost effective technology, but it does have significant costs...
As for the benefits, the old lookup efficiency argument is purely irrelevant in todays world. Switching ASICs can switch IP packets in deterministic time and the hardest part of designing an ASIC is often not the lookup engine.
When mpls was the buzzword of the day a few exuberant network architects where thinking of massivly deploying mpls in full mesh LSPs, with COS differentiation from each edge of the network.
The few people that tried this have burned themselfs quite badly (global center's network statbility problems are usually cited as an example).
So presently the COS/QOS argument is mostly out... face it, QOS is nothing else but to pick which packets get droped on congestion... besides it requires a huge ammount of resources and complexity on routers to enforce and a prohibitive ammount of state to really have any effect... It is much cheaper to put the money in increasing the effective bandwith providing an higher treshold of congestion (optimally above the ammount of traffic carried in the link).
Traffic Engineering (in the sense of diverting traffic out of hot spots) and VPNs (L2 and L3) apear to be the two applications currently on the table.
More than a few people are of the opinion that mpls L3 VPNs do not scale for any acceptable number of customers for which is pratical to deploy service. Personally i believe that the major reason for a service provider to stay away from them is that in an L3 VPN there is no admistrative boundary to diagnose a problem... on a Frame Relay VPN it is easy to figure out if a connectivity problem is in the customer or the SP side... with L3 VPNs the SP will end up having to support any connectivity issue in the VPN... i dont think this is a cost effective model...
Anyway this is a very long rant already...
In a nutshell, technologies are not good or bad, just a set of cost/benefit equations... and don't eat whatever the marketing department feeds you... it is usually BS.
MPLS is not for everyone, and is mainly for private IP networks at present - however, it is very useful in specific applications:
:) ).
1. To provide VPNs (with the same security as the vast number of Frame Relay and ATM networks out there) - the key difference from IPSec is that (a) they run over an IP network owned by a single provider and (b) constrained routing updates are used to limit the visibility of a VPN site. You can't even DoS an MPLS VPN site unless you are in the VPN, whereas IPSec's IKE has some well-known issues with IKE being DoSable. Anyone who is spending large amounts of money on a VPN between sites is best advised to run it on a private network - MPLS VPNs (RFC 2547) are much more scalable than FR/ATM, and the Layer 2 MPLS VPNs have their own limitations (although they are easier to set up for the enterprise). IPSec is much less scalable than the non-encryption VPNs, since gateways have limits on number of IPSec tunnels and on throughput. Whether you use IPSec, FR, ATM or MPLS L3 or L2 VPNs, there is a *lot* of configuration to be done - that's why any large provider is using a provisioning tool such as Orchestream (www.orchestream.com, my employer - yes, I am probably biased
2. Traffic engineering - this means balancing traffic across the various paths in your network - e.g. if you have a northern US and southern US path, and the latter is longer, IP routing will always go via the north, even if the southern US path is underloaded. MPLS TE allows providers to balance some of the traffic onto the southern path, providing better performance and delaying network upgrades. TE can also be used to lay down bandwidth-reserved pipes. However, it's important to note that TE is only one application of MPLS, and other applications do NOT require these 'pipes' (LSPs, label switched paths) - e.g. MPLS VPNs work quite happily without LSPs.
3. Easy upgrade to IPv6 - just migrate your core routers' control software (routing protocols etc) to IPv6, and make them act as MPLS label switches. Only edge switches need IPv6 hardware. However, within a few years most routers will have good IPv6 hardware (Cisco will do hardware acceleration for IPv6 by end of next year).
4. Provisioning of optical light paths - there is a lot of work on GMPLS (Generic MPLS), which will allow SONET cross-connect switches and optical-layer switches to be provisioned with a light path in the same way as MPLS Traffic Engineering.
There is a faction within the IETF that is against anything that adds easier centralised provisioning to IP networks - this is understandable, but IP network providers want to deliver higher-value services today, such as VPNs, and to get more utilisation out of their networks using MPLS Traffic Engineering. There are a lot of these providers at the IETF, but many others are busy running their networks.
IPSec and MPLS both have their place, and can be combined (IPSec over MPLS end to end, or just for the last mile connection).
Finally, for the 'this will destroy the Internet' crowd - having well-managed IP networks using MPLS only serves to make the providers more profitable. Many MPLS networks carry both Internet and private IP traffic, meaning that the everyday traffic can be subsidised by business traffic, just like the way the airlines use business class and flexible ticket pricing to subsidise non-business travellers.
Like several people have already pointed out, you have pretty much missed the point of MPLS. Its pretty easy to throw a MPLS shim header in front of an IP packet, and it makes the job of packet classification a hell of a lot easier (for a taste of what packet classification is like w/o MPLS, or just for some good reading, check out http://citeseer.nj.nec.com/feldmann00tradeoffs.htm l). What you choose to do with that classification really doesnt matter.
I think you discount the QoS benefits too quickly- IMO it wont be long before backbone providers will be charging differently based on different QoS levels ("for $xxx, we can guarantee that 90% of your packets will make it through our network..."). QoS is one of the hottest topics right now, and MPLS takes care of the hardest part automatically.
"The defense of freedom requires the advance of freedom" - George W Bush
MPLS totally sucks. It's the X.25 of the new millenia, just as ATM was the X.25 of the 90's. Why? It's a CIRCUIT SWITCH methodology on top of a PACKET SWITCHING network. Dumb! It's another thing to manage and break from a network engineering point of view. That, and most vendors implementations don't work worth a damn today. There's a few reason it came to be: The IP CIDR lookup problem used to be hard. It's not any more. You can buy off the shelf silicon that does 100M+ lookups with a 256K entrys per chip. This is multi-gigabit packets per second. Music and NetLogic make these chips. And there's proprietery algorithums that do similar speeds. Compare this to when the idea first came out: Doing variable length lookups effeciently were impossible and non-deterministic. Replace that with a fixed size label, and lookup and forwarding speeds went through the roof. This was designed when CPU's were the primary switchers. This is like using a Doom graphics engine compared to a modern OpenGL GeForce3 hardware accelerated engine. Good idea at the time, but the problem that limited you before just don't exist anymore! Oh, and it was largely a Cisco push to kill IPsilion, which had a similar circuit switching methodology. Cisco came out with Tag Switching, and pushed that through which has largely become the MPLS "standards". And don't let ANYONE tell you it's for traffic engineering. What a crock of crap. Yea, you can get a bit of finer control, but you have no idea what price you pay untill your knee deep in it. There's a heck of a lot of power in a IGP/BGP simplistic backbone, it just takes proper network engineering. And QoS... Same deal- load of crap. Here's what QoS really means: Your network is overloaded, and you get to choose who you screw the least, and who gets screwed the most. Fact: No customer pays to be screwed! Everyone wants good network service! So build your network appropriatly, and leave all this crap out of the network. The easiest thing to debug is the fluff you leave out. Little bit of math, little bit of reason, this will get you much farther than MPLS ever will.
The concept behind QoS is that some data streams depend not only on getting data, but getting it in a timely manner (voice, video, real-time nuclear control protocols). Other data streams don't care about how long it takes to deliver, just so the data comes through (ftp, mail, news).
In a general store-and-forward system (like every router & switch I've ever seen), every packet is treated equally. Meaning that the ftp/mail/news packet can get through and make my voice/video packet "late" and therefore unusable.
Quality of Service is all about asking the network if it can provide a certain bandwidth with a certain latency. (QoS as releated to connection contracts is a different matter, which is better termed Traffic Policing.) The network decides if it can provide this to me, and sets up routing tables to handle the connection. The routers now see my new voice/video packet coming in and let it jump the queue ahead of the ftp/web/news packet, because it now understands that the voice/video is worthless unless it gets there on time.
QoS, the FedEx of the Internet.
U.S. Postal Serivce, the standard "who cares when it gets there" delivery method.
IKE, for instance (the key exchange mechanism used by the IPsec security protocol) has also been pronounced "bad" and is going to be replaced or modified.
I gaurantee when you get 2300 people (the current conference attendance) together, they'll disagree on many a topic. The good news is that the (frequenly lively) debates are certainly fun to participate in, hence the reason I came.
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!