The TOSCA Times: Which TOSCA for NFV? Pt 1 – Open Standard Wars

Introduction

At the beginning of this year, I ventured the prediction that 2017 will be “The Year of TOSCA.”
Six months later, the TOSCA landscape has not changed much – except for the projects around it which have changed – and there is a divergence threat on the horizon on which I will elaborate. But TOSCA still is the dominant DSL for the modeling of cloud applications deployment and orchestration, and it is also embraced by the Telco world. “Blessed” by standards communities such as ETSI NFV and MEF, it recently was anointed “lingua franca” by Open Network Automation Platform (ONAP) – the largest Telco open source project around. Even earlier than that, it was incorporated into OpenStack under project Tacker. For full disclosure, another Telco open source project, Open Source MANO (OSM), is not – yet – embracing TOSCA, but rather stays loyal to YANG.
Overall, this is very good news for the TOSCA community, and a well-deserved reward for the small handful of people that have created and are maintaining and enhancing this set of specifications in OASIS. As the saying goes – it is now TOSCA’s turf to lose. Unfortunately, and that is the bad news, it could happen.
As this three-part series will detail, we are increasingly recognizing a trend where open source projects become a feedback loop for existing standards (TOSCA is a very good example), driving bigger scale collaboration based on proven features. This trend needs to be encouraged by standards bodies in order to remain relevant.

TOSCA Videos for Beginners – Learn TOSCA Today!   WATCH THE VIDEOS

Open source – a compass for open standards in midst of a dialect soup

Interestingly enough, what is paining TOSCA now is intricately entangled with one of its great basic principles: under-specification. Different communities are extending TOSCA in different ways, which in fact was the TOSCA Technical Committee’s intent – but a problem this creates is that the TOSCA TC did not publish any best practices for extending TOSCA “the right way.” Sure, TOSCA compliance conformance statements exist, which allows some TOSCA-inspired derivations to claim compliance with the mothership, or not, as the case may be. Some, of course, may falsely claim compliance, even if they are just 25% or so compliant. But the bigger problem the TOSCA community faces is the absence of such guidance, and because of that, it became a free-for-all for TOSCA enthusiasts in all domains, translating into a proliferation of “TOSCA dialects” that in many cases can no longer peacefully co-exist with TOSCA, rendering indigestion to bona-fide TOSCA orchestrators.
Guidance for TOSCA can come from unusual places, in this case from open source communities. In Open-O we think we extended TOSCA “the right way” (in the tosca.compute type) when dealing with support of Enhanced Platform Awareness (EPA) – then followed by pushing support for EPA in the ETSI NFV VNF information model. Now if one would follow the ETSI NFV Information model “to the letter,” the EPA would be pushed into the VDU Compute, which would be “the wrong place.” The figure below illustrates what is meant here by “right” vs “wrong.”

Extending TOSCA (right way on the right) designed and demonstrated in open source

Which NFV?

This brings us to the topic of this blog: which TOSCA for NFV? I could either say “none” or “it’s complicated” (just to be clear, from here on, when referring to TOSCA, I mean Simple TOSCA Profile in YAML v1.x). None, because neither TOSCA, nor any complete and consistent TOSCA dialect specification exists currently that can satisfy all requirements for Telco/NFV. And it is complicated, because in fact it may be better for no such NFV TOSCA-specific dialect to exist.
But such an answer would be a cop-out in the absence of more explanations. So in order to get to “which TOSCA to NFV?”, we may need to first answer the question “which NFV?”
There should not be any debate about ETSI NFV having produced the most comprehensive and relatively complete and consistent set of specifications tackling NFV. Of course, there are also other forums such as MEF, TM Forum, 3GPP, DMTF that also can claim a stake in, and specification for, NFV. And then there are open source projects such as ONAP and OSM, that tend to look at NFV from a more practical perspective. Even then there are particular operators’ deployment environments which may be some mixture of all of the above, in order to make it work. That makes the answer to “which NFV” also quite complicated.
In Part 2 of this three-part series, I will discuss the reasons why ETSI NFV is not the answer for actual NFV implementations and why ONAP has the best chance of becoming the model for Telco NFV.