Open Source (OS) Management and Orchestrations (MANO) is a European Telecommunications Standards Institute (ETSI) initiative that aims to develop a Network Function Virtualization (NFV) MANO software stack, aligned with ETSI NFV. The main goal of MANO is to simplify the onboarding of virtual network components in telco cloud data centers. The initiative has gained impressive momentum among leading Communication Service Providers (CSPs) around the world as part of their NFV programs.

A major limitation of the initial MANO releases was that they only supported one data center. That of course is not acceptable for production NFV, because regulations alone require a distributed infrastructure to ensure service continuity. While there has been much debate as to why CSPs have been slow to roll out NFV into production, the limitations of the initial OS MANO releases have not come up that often.

In October 2016, the OS MANO community addressed the continuity issue with its new RELEASE ONE. More specifically, the latest version of the OS MANO allows the NFV infrastructure and, consequently, the Virtualized Network Functions (VNF) to be distributed across multiple sites. The new OS MANO functionalities making this possible include:

• Multisite Support allowing a single OS MANO deployment to manage and orchestrate VNFs across multiple data centers.
• Network Creation via Graphical User-Interface or automatically by a Service Orchestrator.
• The ability to manage IP parameters such as security groups, IPv4 / IPv6 ranges, gateways, DNS, and other configurations for VNFs.

While these features enable centralized orchestration of highly available network fabrics that span across multiple data centers, the problem is that the OS MANO framework has no mechanism for managing these attributes properly. It is simply assumed that they will come from somewhere—either manually or magically appearing in the service orchestrator—which to me does not represent the level of rigor that is required when designing automated service architectures of tomorrow.

Since any workflow is only as efficient as its slowest phase, leaving undefined manual steps in the NFV orchestration process is likely to create multiple operational and scalability issues down the road. In the case of OS MANO RELEASE ONE, at least the following problems are easy to foresee:

1. Agility. Automating the assignment of logical networks and IP parameters is mandatory to reap the full benefits of end-to-end service automation. Two possible approaches would be to either retrieve this information from a centralized network Configuration and Management Database (CMDB) by the Service Orchestrator, or alternatively by pushing the networks and IP parameters directly into their place. Either way, to ensure the integrity of the configured data and to automate this part of the workflow, the logical networks and IP parameters must be managed within a unified system.
2. Manageability. As the NFV network fabrics span across multiple data centers, the CSPs running these environments need unified real-time visibility into all the tenant networks across all sites. As the multisite model in OS MANO assumes that each data center runs its own dedicated cloud stack for NFV-I, the unified visibility can only be achieved on a layer that sits atop the NFV-Is. Therefore, this is something that either OS MANO should do—or alternatively, there can be a separate layer for the authoritative management of all networks and IP parameters.
3. Administrative Security. The problem with the current OS MANO framework is that it leaves the door open for engineers to manage the network assignments and IP parameters in any way they see fit. An ad hoc approach would typically involve a number of spreadsheets with configurations like security groups in them, which may be rather problematic from the security and regulation compliance perspective since it can easily lead to not having proper authorization and audit trail mechanisms in place.

In fairness to OS MANO, most CSPs still continue to mostly experiment with NFV. It is therefore likely that these operational issues are yet to surface in most telco cloud environments. That said, we have already seen these issues emerge at early NFV adopters, creating unnecessary bottlenecks when the NFV environment is handed over to operations. Therefore, my suggestion to the Open Source MANO community is to establish a best practice for addressing these issues before we reach a point at which they start slowing down the NFV production.