Shared publicly  - 
MPLS is a tunnel. The idea of tagging a frame is to create a tunnel over an IP backbone. Other tunnels are IPv6 RD, GRE, and even NAT.

Ergo: MPLS is duct tape. it's like NAT.

Should we be considering replacing MPLS with simple IPv6 routing and letting the network be a network, not a bunch of tunnels over the backbone.

It's time for MPLS to be over.

Match / Petrol / Discuss.
ASHUTOSH DUBEY's profile photoMrs. Y Iswhy's profile photoMichael Acevedo's profile photoL-euhosc Y's profile photo
MPLS is a tunnel, agreed. It doesn't run over an IP network though. In most cases it will be dual-stack with an IP network, using the IP for it's control plane; however this is not always the case and things like GMPLS and MPLS-TP can run in a network with no IP at all.

Something that I often point out to my colleagues in the optical/transmission space is that if you look deep enough in the packets going over the wires then you will almost always find an IP header in there somewhere, so a lot of the complications in MPLS-TP and MEF style "Carrier Ethernet" are pure overhead and of no actual benefit to the end user.

A lot of this is about trust. At its core MPLS-TP / MEF Ethernet is about OAM. This is needed because carriers don't trust each other and enterprises don't trust carriers. You want less MPLS? Trust your carrier more... </troll>

BTW, a pure IP end-to-end network exists and quite a few people use it. It's called the Internet...
Even though MPLS does exhibit the same generic issues as any tunneling solution ( added complexity, possible mtu problems, etc ) , I don't really see it going away anytime soon.

I don't doubt that in time we'll see, at least in a theoretical level, an MPLS-like solution using flow labels in ipv6. While I do believe that simpler is better, I still see some value in a technology that can also be layer3-agnostic if needed and I can't think of any way to do it that would not require extra encapsulation .

Maybe if there was a standard required MPLS-like header by design, we wouldn't have any mtu issues and we wouldn't have to call it tunneling .
If you consider MPLS to be a tunnel then almost all Telco network protocols have been some form of tunneling. ATM, Frame relay etc.
Exactly correct. ATM, Frame Relay, ISDN, MPLS, FibreChannel, and even TCP are all tunnel or circuit oriented protocols.
If you wanted to get between two of your sites, would you buy two internet connections or some kind of point to point circuit from your telco?
I was with you up to tcp. I look forward to a ringside seat when you submit your "tcp considered harmful" draft...
What's the alternative to setting up a tunneled VPN? PE Access Lists? IPv6 only solves the problem of overlapping address space between customers.
So is radio the only way forward? Cables are all just circuit based tunnels after all :-)
what is your optimal solution then? you say this as my co is just about wrapping up our project to migrate all sites to a dual carrier global mpls network.
You could enforce ipv6+ipsec between all hosts (with your edge firewall ipsec tunneling any appliance devices that can't) instead of buying a VRF based service from a telco.

But I think most companies would consider it all to hard. Microsoft's direct access would meet part of this setup.
+Jeff Polczynski - the alternative to a tunnelled VPN is called "routing". The IPv6 header can mark encryption in the header and doesn't need a "tunnel" to perform encryption.
So are we to assume that all the applications running over this network are perfectly happy being routed over IPv6? I've got 3 mission critical applications that don't support being routed at all, let alone over IPv6.
+Santino Rizzo If the applications can't be routed then neither IPv4 or IPv6 matters. It's not routed.

The point is that tunnels create arbitrary complexity over an IP network. Why not simply let routing do the job that it's good at. MPLS allows stupid things to happen such as MPLS TE. MPLS was implemented so that overlapping IPv4 address spaces could be supported. MPLS exists so that carriers can "add value" instead of providing a good service.

The Internet will might survive an attack, but carrier MPLS networks will not because they are based on circuits and tunnels which have single points of failure, key dependencies and artificial limits on what is "allowed" or "billable".

Lets get back to routing instead of NAT and tunnels.
What then instead of provider managed svcs, use Internet based gone for all sites connectivity? 
Yes. Treat all networks as untrusted and always send data using secure methods. What if the ONLY network is the whole world was the Internet.
True, which is among the intentions of ipv6, all ips are routable. But send all traffic over corp Internet circuits? Intermingle customer inbound traffic with internal data comms? We would just end up ordering additional Internet circuits while preferring some for company traffic and others for Internet traffic anyway. What about the TE and SLA options afforded with PIP? Place unnecessary CAR on our Internet circuits for voip, etc...? 
+Paul Paradiso Regarding TE and SLA's. This assumes that your carrier actually honours their commitment, and that you are able to test and confirm that they are delivering as promised. In the last five years, I've not found a carrier meeting their promises & SLAs within one to two years of implementation.

As their networks change due to upgrades, failures or 'optimisation' they reconfigure services until the rules are broken. The MPLS management platforms are so hopelessly complex, and combined with poor quality service procedures and staff, are unable to deliver the service guarantees.

Until Ethernet and IP service guarantees can easily be measured (not yet), then you should assume that the promises are rubbish.

MPLS TE is so complex, and so difficult to maintain, that carriers regularly cause service outages because of it.

The underlying network is unreliable. Trying to pretend you can "guarantee" anything is a fallacy used to take money for nothing.
MPLS TE at this point is required for large-scale carriers, it's the only efficient way to make use of the many (comparatively) small 10g links that make up the backbones these days, even once bonded with LACP / ml-PPP routing isn't enough, especially once you add links for path diversity.

Also, even with "8 million routes" in a FIB once you do the multiplication on 8-way ECMP for the entire Internet (best case that's 3 million right now), and if any of those links is an aggregate some vendors silently multiply them out as separate routes in the FIB, so 8 4x links would easily blow the route budget.

I'd also add that there are many ways to deploy an MPLS network, some are flexible and resilient, some are strict and predictable, most somewhere in the middle, not all are a few router / pop failures away from catastrophe.

I agree that building services so they operate identically, and securely whether one is on the "inside" or not is ideal. This was something I managed to do at an old job as the few services not delivered over HTTP were mostly mail, and SSH for the tech staff. This was mostly true at my last job also, but as they had somewhat of a Windows culture it took more work.
You are 100% correct. MPLS is tunneling. Its listed, correctly, in the tunneling/overlay section of the Optimal Routing Design book. Tunneling will not go away in the near future in networking. Every other day a new tunneling solution appears (whether its a new application of an existing technology or a new standard altogether).

Its really the application built on top of MPLS that we should be looking at. Is it just because of IP overlap? What about secure network segmentation (reasonably secure, I agree there are potential attack vectors)? What about L2VPN and pseudowires?

You seem to have had some really bad experiences with carriers. Its true they have issues. Do you think there won't be issues with IPv6? That IPv6 won't become complex as we move more and more stuff to it and dream of increasingly complex ways of using it? I don't think its as bad as you say in your comment above. We run our own internal MPLS network. Our NOC can trace a path from PE to PE through the network. Our Tier 2 folks understand how to build VRFs and use route-targets. Its not that hard. With BFD, we have 300ms or less recovery time for a single link or single node failure.

But lets talk about just going to IPv6 for a second. About three years ago our company merged with another company. On both sides of the fence (at the time) there were these massive projects to integrate the cobweb of networks that had been amassed through the years by acquisition or through organic growth. Both projects involved re-addressing massive parts of the network. Both projects involved re-numbering many VLANs. It turns out, this just isn't feasible at a large scale. Too many dependencies, too much risk, and just not a clear pay-off in following through with the job. In fact, there had been a history of such projects on both sides. We used MPLS to help solve this problem. We used MPLS to reduce the number firewalls that traffic had to transit between datacenters. In some cases to zero, as when we extended a network from one Data Center to another. We could so natively without NATing or passing through multiple firewalls managed by different teams.

But isn't "just going to IPv6" a similar pipedream? We have a lot applications. A lot of appliances. We have numerous lines of business and networks with many stakeholders who need to understand the risk and the pay-off. I just don't see this happening right now across the board. I like Ethan Bank's approach: We'll probably need to start in the DMZ/extranet where we interface with other networks that may have already converted to IPv6.
I think that a native IPv6 network would be more predictable, more capable, more _better_ than any MPLS network. Overlays, tunnels and NAT always bring complexity into a network that creates failure, in multiple modes, in many different ways.

What value does this really bring ? can you quantify the business loss due to these issues ?
You can reduce the number of firewalls and the number of NAT points. You can simplify the routing (in the context of the VPN). You can reduce the amount of time it takes to move an environment into a Data Center. If the MPLS infrastructure is already there then you don't need to build new circuits or order gear or find ways to prevent the mixing of traffic between security zones. Build a VRF in each data center. The WAN part is done. Do we really want to expose our ourselve to the risk of one universal routing-table for all things in the WAN with firewalls around the edges? Do you propose we have DMZ servers and application core servers on the same subnet or juts attached to the same router?

Unless you want to keep things separate physically than I don't see how you can get away from having overlays. Even in with IPv6.
As others have said above it sounds like you have had some really bad experiences.

We also run and operate our own MPLS network and whilst I can imagine that it can be engineered to be a huge PITA our network is stable and can sustain multiple node failures without causing issues and with a fast failover (BFD).

On the other side of the coin we deal with other suppliers for circuits in areas that we do not have a presence (the rest of Europe) and we have been on the receiving end of issues on their MPLS network one too many times.
Quite simply, try designing or maintaining a MPLS Network using Alcatel-Lucent Service Routers like the SR 7750, and you will love MPLS all over again...
Even if you do away with all the overlays (vll,vrf,vpls) and go with internet only MPLS won't go away. Can anyone name a large ISP that doesn't use MPLS in their network core?
Paul, just +1 the post should do it. 
Hmmm, do you think VLANs are just tunnels over vast L2 network?
In the interest of full disclosure, I might be slightly in love with MPLS. There really is some complexity about it which can leave the NOC feeling like they are in the water without a life-raft.
Ok, I really, really tried to stay away from this one, since it's an obvious flamebait, but can't help myself (I guess it works then). :) So here it goes.

I would really like to see an ISP network operated with only "simple IP routing". This would mean you can forget about TE, except if you were willing or crazy enough to do offline IGP metric optimization, which is an absolutely sub-optimal way of doing TE. I guess you would then be also willing to be at the mercy of statistical shortest path multiplexing of flows - good luck with that and with explaining why you have to grow some of your pipes excessively while there's still so much of free BW on alternative paths.

Until we get another good solution for TE, I do not see MPLS going away. The question is still out there whether this will be a distributed or a centralized solution. There has been quite a lot work done on OpenFlow lately, so that could be an option if vendors start supporting it. I'm not a believer yet though, and there are quite a few pending issues there.

Also, please don't mix up MPLS with GRE or any other tunnels. Those are completely different technologies with different issues. Ivan (as usual) explained this very well (hey, Ivan, how are things?).

And please, please don't compare MPLS to NAT as being on the same level of brokeness. NAT is a total kludge that improves exactly nothing and breaks end-to-end connectivity (don't get me started on carrier-grade NAT). MPLS brings a wealth of features to IP (some better some worse) many of them currently still indispensable and without a real alternative.

Hi Mark! Long time, no hear. Coming to Slovenia in the near future or shall I find a good reason to travel to ... where exactly? ;)
Well, I agree with Greg. I believe future will be of pure IP networks with no requirement of having complexity of another layer 2.5. More and more clean we keep the underlying technologies more efficient, fast and easy-to-maintain our networks would be. Encapsulation, tagging, tunneling have been our work arounds for years to survive in this complicated world of hetrogeneous networks where service providers have launched their own individual products in the market suiting their portfolios but in return creating an overall massively complicated, un-uniformed global internet.

With the complexity of Internet we have seen in the past I hope we use our lessons learned while developing our new IPv6 networks which will be the foundation of our future internet. Though I agree it will take quiet an amount of time to replace MPLS but I would love to see our data across the globe riding on a pure IP packet :-)
Add a comment...