Almost two years ago, this Heavy Reading whitepaper came out. Today, NFV MANO is still an issue that is holding back NFV. Don’t get me wrong, the concept of an orchestration layer to manage different VNFs from different vendors is good. The promise of best of breed VNF software being plugged into an overall NFV solution is great. We are just not there yet. Not even close.
In fact, where we are is not in a great space. And it’s not surprising, really. Why would a large telecom infrastructure company that has many potential VNFs want to make them available to compete in a real “best of breed” concept? Why not just make sure they all work together, and work together with their MANO? And guess what? That’s where we are.
The service providers who want to deploy VNF solutions, are not exactly converging to a common approach, which is ultimately just slowing down deployments. Large SPs, predictably, are using their own clouds, which means they have their own requirements. And this means the larger companies who have the resources have a leg up on getting multiple VNFs to address them at one time. Which means that the vendor lock-in issues that NFV was supposed to address are not really being addressed.
So what do we do about it? Certainly, organizations like OPNFV are helping. In fact, Dialogic has established an internal OPNFV OpenStack test bed and product proving ground platform for our VNF certification. The OPNFV Cloud/NFV proving ground, a Continuous Integration/Continuous Delivery (CI/CD) environment, will provide automated management and configuration of Dialogic’s internal compute, storage, and networking resources used for the developmental cloud compatibility and functionality testing of Dialogic’s virtualized media, signaling, and application layer solutions. It will initially be based on the OPNFV Brahmaputra release.
This is just one step in making NFV a more democratized network architecture as many have hoped. If we continue the effort, slowly but surely, it’ll help make deployments faster.
