A Common Schema is More Important than the Modeling Language.

In the SDxCentral byline article, “The TOSCA and YANG Debates Miss the Point – It Should all be About the Schema“, RIFT.io’s Rene Tio wrote about the importance of schema when debating the merits of TOSCA, YANG, and any other modeling language. The topic originated from frequent discussions the RIFT.io technical and support teams have been having with our customers. The questions about TOSCA and YANG have become more frequent because many of the NFV and orchestration vendors are using the terms in their marketing pitches. I joined RIFT.io over two years ago and as the NFV market has evolved and matured, I’ve naturally followed the evolution of marketing and messaging. A couple years ago, every NFV and NFV MANO vendor latched onto the ETSI working group’s first NFV and NFV MANO specification as the standard way to describe how their product fit in as an NFVi, VIM, VNF, NFVO, VNFM, etc.

Fast forward two years and now orchestration and automation software is understood as the critical foundation for actual production-ready NFV/SDN deployments. And predictably, marketing engines (of which I am part) are now revving up new buzzwords like TOSCA, YANG, YAML, etc. I have nothing against marketing buzz – that’s my job. But unfortunately, the marketing buzz, especially when it tries to deliver simple messaging for esoteric topics such as standards and information and data models, often sows confusion with customers.

Because we at RIFT.io have a gotten so many questions about TOSCA and YANG, I sat down with our CTO and OSM TSC member, Matt Harper and our VP of Product Management, Rene Tio for a Q & A. The goal was to get past the marketing messages and unravel some of the misconceptions and misunderstandings. We contributed our story to SDxCentral but also wanted to provide the complete Q&A here for more detail. The bottom line is this: The industry would be much better off if we stop concerning ourselves with which language is better and instead focus on creating a common, proper schema. If the industry coalesces around a schema, it won’t matter which language a data model is presented in, every vendor will be able to translate freely among them. Check out the SDxCentral article and read on for some great explaining.

Matt Harper
Rene Tio
RIFT.io, VP of Product Management

Can you provide some background on TOSCA and YANG and their evolution?

Matt–Sure. The term “TOSCA” [Topology and Orchestration for Cloud Applications] is used to describe the OASIS standardization efforts around cloud orchestration. TOSCA is a large, somewhat generic, and incomplete specification; it’s a hybrid information-model/data-model based on YAML.  Since it is loosely defined and incomplete, commercial MANO vendors have each defined their own YAML DSL (Domain Specific Language), each a proprietary and enhanced TOSCA model.

The term, “YANG” refers to the IETF Data Modeling Language. YANG is used to very precisely model configuration and state change information.  In fact, YANG specifications are so precise that they can be compiled into data parsers/validators and can even automatically be compiled into transactional NETCONF operations. It is also possible to compile YANG specifications into a YAML DSL with associated data model parsers/validation checkers.

What are the strengths and weaknesses of TOSCA?

Matt–TOSCA features a YAML descriptor format and is best suited for launching VMs and running scripts in response to events. However, a major disadvantage of TOSCA is its large, loose specification and the fact that it is governed by a very large technical committee of over 150 people from over 40 companies trying to address all cloud applications. Consequently, there are many vendor specific extensions, which inhibits interoperability. TOSCA lacks a formal model for life cycle events; life cycle events are handled via vendor-specific scripts.

Are there efforts underway to address some of these limitations?

Matt–Recognizing these deficiencies for NFV, OASIS attempted to define a minimal TOSCA Simple for NFV, but it was too basic. This led to yet more vendor-specific TOSCA variants. There are new vendor efforts in progress to create a de facto “standard” TOSCA model for NFV use cases that would work across multiple vendor’s MANO products. Due to the TOSCA specification being very loose and vendor-extensible, the effort centers around providing a common YAML parser (based on open-source ARIA core) that would potentially define a new de-facto standard.  There are also efforts in progress to tightly link a TOSCA-based schema to the ETSI MANO specifications like has been done with the formal YANG models under ETSI.

Rene–Our main goals as we work with OSM and our customers on information models include to first ensure that when the information model is specified, that vendor implementations cannot be left to interpretation. Secondly, the model should encode all life cycle events so that the need to use scripts or an external entity to change the life cycle state of the VNF or Network Service under the Orchestrator is minimized. Thirdly, the model needs to be sufficiently abstracted to accommodate all VIMs, all VNFs, and all use cases (“write once deploy many”).

We find today that the first goal mentioned above isn’t fully satisfied by ETSI Group Specification, IFA 011: “Network Functions Virtualisation (NFV); Management and Orchestration; VNF Packaging Specification. While concepts such as life cycle states and events are very well described, it only specifies for example objects, attributes, relationships, and unidirectional cardinality.  To this we need to add more implementation-related details like type, default / min / max values, and the like.  The goal is to leave no room for interpretation, which promotes interoperability.

The issue with TOSCA is as Matt says, it is very far behind even IFA 011.  Vendor implementations differ, and key features are missing, such as:

  • No Enhanced Platform Awareness (EPA) support
  • Life cycle events are scripted instead of using models, which causes orchestrators to lose track of VNF or NS state
  • TOSCA descriptors that we have seen contain VIM-specific attributes, which results in different descriptors for different VIMs – this violates our goal of “write once deploy many”.

What are the strengths and weaknesses of YANG?

Matt–As with TOSCA, YANG is a YAML descriptor format. The strength of YANG is that it is a very precise data model specification. Within ETSI, a small, expert technical committee defined the actual data model. All key concepts are fully modeled (e.g. VDU, VNF, NS, Virtual-Links, VNFFG, etc.). In contrast to TOSCA, ETSI OSM’s YANG-based format models life cycle events – most life cycle events are handled via modeled configuration rather than via custom user-defined scripts. YANG also features a well-defined mechanism to propagate dynamic metadata into templated configuration and between VNFs.

What are the biggest misunderstandings and/or misperceptions of TOSCA and YANG?

Rene–One of the big misunderstandings, often promulgated by MANO vendors, is the claim that TOSCA is superior for orchestration and that YANG is only good for device configuration. The issue is that, as of today, there is no generally accepted data model based on TOSCA that can be used for NFV orchestration as ETSI intended.

Instead of arguing which language is better, the industry should focus on creating the proper schema. If an industry-wide agreed-upon schema exists, then it does not matter which language a data model is presented in, whether it’s TOSCA, YANG, YAML, etc. We would then be able to translate freely between these languages with no loss of information. More importantly, all vendor implementations would agree and interoperability would improve.

What are the things that ETSI and OSM have been working on to address the challenges of TOSCA and what has RIFT.io contributed?

Matt–RIFT.io worked within the ETSI OSM community to define an ETSI YANG model complete enough to be used in production. The focus of the ETSI YANG model is creating virtual networks that co-exist with physical elements, deploying services on top of them, and applying configuration and model-driven life cycle management.

OSM completed the work of the ETSI NFV working group and defined a precise YANG data model for the ETSI MANO information model. OSM uses a YAML form of the YANG model for actual VNF and Network Service descriptors.

Rene–OSM and RIFT.io have spent most of the effort in defining a strict schema for the NFV descriptors.  This ensures interoperability between vendors and makes integration and deployments easy. OSM and RIFT.io chose YANG as the starting point because YANG-derived schemas are both very expressive and extremely precise.  Furthermore, the YANG model was developed to expresses intent and specifically avoids incorporating VIM-specific attributes into the model; this allows the exact same descriptors to be optimally deployed across various VIMs (e.g. OpenStack, VMware, etc.).

What recommendations do you have for service providers when confronted by marketing claims

Matt–SPs should ask their MANO vendors what Open Information Model (IM) their products support and if their products have limitations that restrict them from working with either TOSCA-based or YANG-modeled descriptors.

Rene–Not all “open” is created equal, particularly when information models are concerned.  Just because you can find it on github doesn’t mean it isn’t proprietary.  Only when “open” is backed by a strong community will there be broad agreement, and only then can you truly avoid vendor lock-in.