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:
Keep reading on Light Reading.