The TOSCA Times: Which TOSCA for NFV? Pt 3 – Future TOSCA With ONAP

Please first read Part 1 and Part 2 of this open NFV standards series. In Part 2 of this series, I wrote about 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.

The dangers of TOSCA divergence

With all the analysis provided in this blog, and with so many remaining questions marks, the only way to answer the “which TOSCA for NFV?” question is by heavily qualifying the answer.
For those that are looking for an implementation following relatively strictly the ETSI NFV VNF/NS information models in the next 9 months, the answer is the ETSI NFV SOL001 specification, currently a work-in-progress. Until recently, ETSI NFV’s SOL001 was referring to work currently done by the NFV ad-hoc group as TOSCA Simple Profile for NFV. That group is truly struggling as we speak to provide what NFV needs, because of two frequently conflicting principles at play: the desire to match as closely as possible the ETSI NFV VNF/NS information models for VNFD/NSD versus the desire to reuse as much as possible from the existing TOSCA types.
Unfortunately, as though an NFV profile branching out from the Simple YAML was apparently not enough for the dark forces of “not invented here,” there currently is an imminent risk for further divergence, with ETSI NFV SOl001 considering completing an NFV profile within ETSI NFV, divorced from a potential NFV profile specification that may continue to completion within OASIS/TOSCA TC. As someone recently said during a recent ETSI NFV meeting “two NFV profiles may be better than none.”

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

I personally doubt it. Sure, you can have 1000 NFV profiles, but aren’t standards bodies supposed to cooperate and provide industry guidance? What suddenly happened to the “turf infringement” that ETSI NFV was so concerned with 4 years ago? What are TOSCA orchestrators supposed to implement? Two different profiles, or perhaps more? What kind of industry guidance is that from SDOs? As a long-term fan of and contributor to standards, and ETSI NFV in particular, I have to say that if ETSI NFV drives such a split in the industry, I will be very disappointed. The figure below shows the TOSCA landscape shaken by this potential latest divergence.

The “Babylon Tower” danger – adding complexity with no real added value

For those that are looking for a more pragmatic approach (e.g. in ONAP), I am hopeful that ONAP will rise to the occasion and produce an ONAP community TOSCA dialect that serves its approach to VNF and NS design and modeling. In Release 1, for the VoLTE use case, ONAP has decided to use a version of the OASIS/TOSCA TC NFV profile published in May 2017. It is a version that is by no means complete, and may already be obsolete. While ETSI NFV VNF and NS information models are considered good starting points, I expect that the ONAP information models will look somewhat different – both removing and adding to the ETSI NFV models – and that will also impact what TOSCA dialect is needed.
While in Release 1, ONAP is opportunistically using different versions of TOSCA dialects (almost every ONAP component that processes TOSCA comes with its own different TOSCA parser), I think ONAP needs to evolve towards the use of a single TOSCA DSL regardless of specific component that uses it, and either consolidate on the use of a single parser/processor or make all TOSCA contributed parsers capable of processing the single common TOSCA dialect. What that dialect will look like is too early to tell; but ONAP must strive towards a TOSCA dialect that is not NFV-specific, not even Telco-specific, but rather cloud application specific, while inclusive of addressing all networking requirements.
If a short-term tactical decision needs to be made for R2, and two (or more) NFV profiles exist, I recommend ONAP start from the NFV profile that OASIS/TOSCA TC offers, if available in time, rather than from one that may be offered by ETSI NFV. While the two may only have subtle differences, the one that may be produced by OASIS/TOSCA TC will always carry the benefit of more scrutiny by TOSCA experts.

Which TOSCA for NFV?

Those of us that take the long-term view for Telco, and believe that IT/Enterprise and Telco need to remove barriers rather than add more, we imagine a time not so far in the future where NFV is no longer sticking out like a sore thumb, but is rather an intrinsically adopted part of Telco. For us, the answer is a “changed TOSCA.” That is, a convergent TOSCA that allows to build data models fulfilling the requirements of any information model (including the ETSI NFV VNF/NS information models), not just of a particularly constrained information model.
That future TOSCA needs to:

• move away from “normative types”, and instead support types to be created by picking and choosing bundles of capabilities. By doing this, we would no longer be stuck with working around the inheritance problems of node types (which should be domain specific), while capabilities become the commodities that can be shared regardless of domain
• overhaul networking types, the weakest link of current TOSCA, focusing on creating forwarding graphs based on requirements and capabilities
• add better support for lifecycle management/Day2, policies, telemetry and licensing
• support runtime service composition
• provide better mechanisms for cooperation between declarative and imperative workflows
• … and probably more

How can this be achieved? There is a path via ONAP long-term strategy, and incremental implementation and adoption, while also engaging OASIS/TOSCA TC.

The future-proof way forward for TOSCA: pure model driven

So “which TOSCA for NFV?” Quite possibly the one TOSCA specification where NFV no longer figures into the specification name, but that supports NFV, and more importantly Telco as a whole much better.
Should we call it TOSCA 2.0?