Defining MANO: Open Source vs. Standards
Prayson Pate, CTO, Ensemble, ADVA Optical Networking
As service providers are working to deploy NFV-based services, they are finding that management and orchestration (MANO) is a pain point. One of the big questions about MANO is how we go from a high-level architecture diagram to interoperable implementations. Do we take the traditional telco path and work through standards bodies? Or do we take a cloud-centric path and focus on open source development projects?
Standards development organizations (SDOs) -- Tried and true
The telco world is driven by standards that have been developed by a variety of SDOs and related bodies, including ETSI, ANSI, IETF, IEEE, ITU-T, ATIS, TM Forum, Telcordia, TIA, IEC and others. These SDOs produce detailed specifications in a communal fashion reflecting the needs of the operators, the suppliers and regulators to various degrees. However, there are some drawbacks to this approach:
- Slowness -- SDOs typically take months or even years to develop or update standards. That is too long in a world that moves at Internet speed.
- Impracticality -- The standards produced by an SDO may not be workable, complete or practical when implemented for real applications.
- Irrelevance -- SDOs may produce standards that donít focus on the essential aspects of a technology, and may omit definitions of critical components or interfaces.
Open source projects -- Consensus and code
Cloud-centric technologies and applications have bypassed the SDO approach in favor of de facto standards which are often the result of open source software projects. The dynamic and community nature of open source projects ensures that they do not trip over the previously listed issues experienced by SDOs. However, open source projects may have their own issues and priorities:
- Competing projects -- There are often multiple open source projects working on substantially the same application. For example, Open Source MANO, Open-O, Open Baton and eCOMP are all addressing NFV MANO orchestration. The result is a dilution of effort.
- Rate of change -- Open source projects will typically have two, three or four releases per year, often with significant changes to APIs and behavior. Consuming these releases is a difficult and time-consuming effort, especially given the next issue.
- Version compatibility -- There may not be backwards compatibility between versions, complicating migration and upgrade operations.
- Long-term support -- Open source projects depend on broad-based community support for success. If a given project loses that support then the project may die, leaving the remaining users stranded.
The sands are shifting
This question of standards versus open source is starting to appear in articles and conferences. Sterling Perrin of Heavy Reading raised this issue and reported the result of industry polls. The image below shows his results presented at a recent conference:
As shown, there is a shift in importance attributed to the various bodies. Open source projects such as OpenStack, ONF and OpenDaylight have increasing importance to operators. At the same time, organizations such as ATIS, TIA, ITU-T, ASNI and the TM Forum are decreasing in importance.
The battle is just beginning
The battle is coming down to speed versus risk. Operators see the need for both traditional SDOs and forward thinking open source projects, but the trend is to focus more heavily on the latter. SDOs are starting to respond by trying to move faster, as well as by supporting their own open source efforts. For example, the MEF is supporting open source efforts to implement its Lifecycle Service Orchestration vision architecture. I personally think that this is the right approach, and enables traditional SDO work to be leavened with real-world feedback and testable implementations. It will be interesting to see if other SDOs follow suit. One thing is for sure -- the SDOs won't just go away.
— Prayson Pate, CTO, Ensemble, ADVA Optical Networking