For your security concern you are right at some level IMO. CIA which stands for confidentiality, integrity and availability should be in place for any critical data which needs to be protect.

If we look these three major field for VPNs, obviously if you are not encrypting your data, at least at service provider can be read, can be eavesdropping. But this is not weakness of MPLS, almost all overlays ( except IPSEC enabled DMVPN, GETVPN so on) works like this. So for confidentiality, another overlay , generally GETVPN is suggested over MPLS VPN since it is best suitable over the private VAN.

For integrity, you are also correct. There is no built in authentication/hashing alghoritm for MPLS. But again this is not weakness of MPLS, whatever technology you use, unless you are not implementing authentication maybe with preshared key or with certificates, you can not make sure from the integrity of packets.( For the link level errors some overlays use CRC for basic integrity check)

For availability, MPLS may or may not give you additional benefit based on which application of MPLS you implement.For example you might be implemented MPLS Traffic Engineering for local or path protection and you can get 50ms convergence time which is more than enough for most of the application.

Conclusion : MPLS is not weak from the security point of view compare to pure IP network, even maybe can be seen as more secure if you accept abstraction/segmentation as security parameters.

Sounds really impressive answer Thank You @OrhanErgun. But with same when i overview security challanges with MPLS, I cannot deny the fact that there is no guarantee to VPN users that packets do not get read or corrupted when in transit over the MPLS core.

Historical reason for the MPLS was performance. Since for IP destination IP hop by hop lookup it used to consume more CPU than label based forwarding. But this is not anymore concern and use case for MPLS.

Recent enhancements of IP also can gives us some of them. For example IP FRR with LFA and Remote LFA gives us to ability fast reroute.VRF lite can give us similar segmentation wth the MPLS but it is limited scale.

GRE, DMVPN,Get VPN, L2TPv3 can give us VPN capability again with the limitations and restrictions. For bandwith optimization, on small scale networks still PBR, Static routing might be an option but MPLS Traffic Engineering's primary driver is this case.

So our reason for MPLS is not the QoS. Intserv and Diffserv QoS is used both in MPLS and IP world. Even with MPLS especially for Intserv several enhancment has been made for RSVP to support MPLS Traffic Engineering.

Thanks jgherbert for your comment. Maybe I should have change the article name to Today's distributed architecture holds it's intelligence at the edge. For controller based approach, I would argue that it will be again at the edge if controller is placed as virtual. But at least hardware (switches, routers) will not keep same amount of state, will not have to be topology aware, running complex alghoritms so on.

Also which PIN the controller will be managing is important IMO. If you deployed it in the DC, still your WAN module might have two or three layer boundaries, so everything for the distributed architecture would be true.

- Topology awareness /somewhere/. This doesn't have to be in the egde or the core; it could well sit in a controller device that doesn't reside in the network architecture per se.

- Brains at the edge. Or, at least, the ability to enforce policies. Where the egde obtains those policies is another question. Perhaps they are self-sufficient, or perhaps they rely on another source to program them.

As to moving security to the hypervisor, sure, have at it. Double up in he network? For sure too. Now figure out how to sync those two so that there's a consistent policy in place without doubling up on the administration required to maintain it. Part of VMWare's argument for hypervisor security, as I recall, is that you get to implement policy prior to encapsulation in VXLAN. I seem to recall that part of Cisco's ACI pitch is that the ACI chip can look inside VXLAN are wire speed and process policies against it. If so, that particular argument for VMWare begins to falter, especially if you have more than just VMWare in your network (I know I do). VMWare position the 'edge' as being the hypervisor (with the brains), and then the rest of the network (access AND core) are relegated to 'dumb'. I maintain that unless you're in the lucky position (YMMV) to run nothing but VMWare overlays, you'd absolutely better have that defence in layers that we mentioned.

Brain should have visibility of course but summarization always should be put in place. Thus floding domain boundary for layer 2 and layer3 control plane should be kept at minimum. As an example you dont want to extend spanning tree to multiple domains also you dont want to extend your IGP as flat to everywhere if scaling is concern.

You separate complexity from complexity so if your edge is hub and spoke topology, you want to isolate that module complexity from your core which maybe partial/full mesh or ring.

So, I agree with some part of your comment but every PIN actually requires careful attention. If we accept brain should have visibility and then if we say core should have full visibility then both would be wrong. Brain should have different capabilities as well in addition to visibility but not full visibility since this is distributed architecture. For SDN, SDDC talk we could maybe say that.

If we also say core should have full visibility IMO this would be also wrong since you want most of the time hide the topology and summarize the reachability if suboptimality and/or blackhole is not a big concern than scaling and convergence.

I think the brain should have full visibility and knowledge of every angle and leaf within a system and this is what you can see from the Network core point of view while the edge is specialized to do certain functions on limited area within the network without full knowledge of what is happening on the entire network

Our latest survey shows growing demand, fixed budgets, and good reason why resellers and vendors must fight to remain relevant. One thing's for sure: The data center is poised for a wild ride, and no one wants to be left behind.