The Importance of an Open Source MANO Community
Telephonica recently joined the ranks of 22 service providers and ISPs in creating an Open Source MANO Community.
Radware is also a member of the Open Source Mano (OSM) project. We believe it is a welcome initiative that will help expedite the adoption of NFV since it tackles some of the biggest barriers.
The lack of a unified end-to-end service deployment model is problematic for all players in the NFV market: For VNF vendors, it results in duplication of integration work; not only do we need to develop specialized deployment descriptors, but more importantly (and painfully), integration into different MANO stacks, requires tight collaboration with vendors of such stacks, to develop the full automation of end-to-end service life cycle processes. Clearly, this requires from VNF, and MANO stack, vendors a lot of resources.
For MANO vendors, not only does it implies additional development efforts, as for VNF vendors, but more importantly, it creates closed eco-systems where each MANO stack can properly support only those VNFs that have been explicitly integrated into their system.
Finally, it forces service providers to select entire closed eco-systems instead of desired open, pluggable system envisioned by the originators of the NFV transformation.
The backing of ETSI and a growing list of major service providers indicates that OSM has the potential of not just becoming yet another MANO stack, but to create a reference implementation that properly covers end-to-end service life cycle automation including the much needed uniform deployment model. The success of an open and unifying project, such as OSM, will encourage reusability and plug ability across the entire spectrum, which in turn will lead to faster innovation since resources freed from repetitive duplicate work, can now focus on advancing the state of the art.
At Radware we intent to follow closely the progress of this important project and contribute our expertise and know-how to ensure its success, in particular we would focus on the mechanisms needed for full automation and configuration of VNFs after initial provisioning of resources and connectivity, i.e., automation of Day 2+ configuration processes.