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. "
Maybe I haven't gotten over the 8 hour jet-lag yet like I thought I had...
s/pronounced/proclaimed/g
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
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
My point was that MPLS VPNs *re-use* existing routing protocols such as BGP, OSPF and RIP, rather than re-inventing the wheel. MPLS doesn't do encryption so it doesn't need encryption keys. The customer site on a VPN doesn't need to know it's in a VPN, and needs no special configuration - it just peers with the provider edge router, as with any other router.
There are some people who have done dynamic protocols for VPN node discovery for both IPSec and MPLS VPNs, but the problem is somewhat simpler in the MPLS case.
Please read a bit about MPLS VPNs, then this will become much clearer - a good site to start at is www.mplsrc.com.
MPLS was great before we had ASIC's that were doing full next hop lookups at OC-48 and OC-192 speeds... Now with routers actually forwarding at those line rates, the need for MPLS has dwindled... But... I believe that the ability to provide the amount of traffic engineering and VPN's afforded with MPLS is a viable solution that is here to stay for a good while. Back when I was working on a 38 POP network with multiple private peering points MPLS was going to provide a lot of the benefits of ATM on our POS network with out the fscking cell tax... These days things are a little different in the office, but I still am waiting for a good excuse to fire the MPLS up on the damn M-40's and have a good time...
2.5 > 2 - True
2.5 >= 3 - False
Hmm... so... whaddaya think?
BTW, yes, I am nitpicking here, but this was too funny not to respond to. :)
MPLS is NOT just a circuit switching technology - unless you are doing MPLS traffic engineering, the normal IP routing updates from your IGP drive the propagation of labels via LDP (Label Distribution Protocol). If you follow the labels, they are more like a tree than a circuit in many topologies. If you use TE, you can lay down 'circuits' but these are optional - you don't have to do TE on every part of your network, and mostly this is only done in core networks.
People are using MPLS for VPNs and other applications, not just traffic engineering. It's also a great way of turning ATM switches into IP routers, which is something that the IP people should be enjoying (ATM was going to kill IP, now IP is taking over ATM)...
As for the hardware issue - this is irrelevant, MPLS is not being used to speed up obsolete hardware, it's being used on some of the fastest routers around (Juniper M160 and Cisco 12416), for its usefulness, not just for its speed.
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:
The goal should be whatever lets providers deliver services that customers will pay for, IMO. In any case, MPLS does fit into the 'dumb core' model quite well, just like DiffServ - core MPLS routers don't have a lot of state, and just swap labels most of the time. This is a lot closer to the 'dumb network' architecture than the traditional PSTN approach where every switch has a great deal of complexity.
Yes some people say it is not "bad" it just needs a bit of work because it is hard to use, hard to implement correctly (with out help or a lot of experience), and generally misunderstood. That's a complex way of saying "bad" in my mind. It doesn't, however, mean that it can't be touched up to make it "good". Specifically, removing some of the unused options is generally believed to be one solution that will help make it more easily implemented and used (a view I generally agree with).
How many times did you read the RFCs before understanding them. And if you re-read them again, I bet you'd learn something new (again).
/Wes -- I was there too
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
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.
I can't remember the main URL, but since my FOLK project uses it, I've a link from the FOLK pages.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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
QoS: For when you don't want to kill MP3s, but still want people to be able to read their e-mail. Great for college campuses. After all, media sharing is like a gas - it fills to expand whatever bandwidth you give it.
SIG: HUP
Say from California to New York. . . . When a packet arrives at a MPLS router (head end router) in New York the router encapsulates it...... Finally the router at the end of the LSP (in New York in our example) removes the MPLS encapsulation
This MPLS thing looks impressive: it can send packets safely from New York to New York without getting mugged. Where can I get one?
Just because they all love St. Paul doesn't mean they can bash MPLS that much! Oh, wait. They don't mean Minneapolis, do they. Nevermind.
That green slime had it coming.
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.
MPLS doesn't have much to do with packet classification for QoS - you can easily encode the result of a classification decision today in IPv4, by marking the 3 bit IP Precedence (or the 6 bit DiffServ codepoint) in the TOS byte. So an edge router looks at (say) source and dest IP address, and source and dest ports, and marks this as a single byte, so that other routers can avoid unnecessary processing and memory references.
In IPv6 you can encode the result of classifications on a per-flow basis (e.g. a VoIP call, rather than a class which is for all VoIP traffic) - this is what the Flow Label (16 bits) does, though it's unclear how much this will be used since it's dependent on per-flow RSVP being deployed.
MPLS does support using 3 bits (the EXPerimental bits) in the label to mark class of service values, just like IP Precedence - most MPLS edge routers automatically copy the IP Precedence into these bits. It can also let you reserve bandwidth etc for MPLS Traffic Engineered paths through the network, which can be a good way of guaranteeing QoS through the MPLS network. However, this has little to do with classification, which normally happens in the pure IP domain, closer to the edge of the network.
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.
That's an odd pronunciation...
--
"Karma can only be portioned out by the cosmos." - Homer Simpson [1F10]
Now, let's say that VPN configuration was as complex as Internet routing. Why develop MPLS when all you you want is a dynamic update of VPN configuration information? Why do all the routers in between the VPN endpoints need to do something different? And, as I indicated, you still have the (dynamic) key distribution problem, unless you send plaintext data outside your network (shudder).
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!
I'll just address the VPN issue, there are plenty of others I could comment on...
All VPN packets are labelled twice - once to get them from site to site, and once to get them from PE router to PE router. Only the second (outermost) label is visible to core (P) label switch routers. Hence there is absolutely no LSP state in the core relating to VPNs. Similarly, the core LSRs don't have any per-VPN routing state, since this is kept only in the PE routers.
By all means, criticise MPLS, but please get your facts right.
Routing protocols such as RIP and OSPF are used by enterprises over VPNs so that each router or IPSec gateway has routes to all other routers/gateways. In IPSec VPNs, you may have to configure this manually - some people use GRE tunnels instead of IPSec SAs purely so they can run a routing protocol to avoid this. Installing all of this from a central file is just returning to the days before dynamic routing protocols (i.e. pre-ARPANET).
MPLS VPNs are based on running the enterprise's routing protocol throughout the VPN, so there is no need to manually configure static routes everywhere (which is what your posting describes). Actually MPLS VPNs encapsulate the routing updates across the core, so that core routers never see the full VPN routing tables, but the effect is the same.