TOSCA vs. YANG

In the networking world, YANG has become the de-facto data modeling standard. For cloud applications, TOSCA is getting all the buzz. NFV straddles both worlds and is getting pull from both the YANG and the TOSCA camps. One could ask then if we really need two languages? Shouldn’t we standardize on one, and if so, which one?

While these may sound like fair questions, they assume that both languages serve the same purpose and therefore are interchangeable. However, if we take a closer look at both languages, it becomes clear fairly quickly that this is not the case. TOSCA and YANG are in fact quite different. In a nutshell, YANG is a data modeling language while TOSCA is a service automation language.

YANG is in essence a replacement for SNMP MIBs. YANG models define the schema for configuration and state data of networking devices, and network management tools use the NETCONF protocol to manipulate these data. In the SDN world, YANG has been adopted as a general-purpose modeling language that can be used independent of NETCONF (for example, YANG defines the data models for the model-driven service abstraction layer (MD-SAL) in OpenDaylight) but it is still strictly a data modeling language: it defines data schema without associating any semantics with the data that are being modeled.

TOSCA, on the other hand, was designed as an automation language for deploying and managing cloud services. Unlike many other automation tools, TOSCA uses a declarative approach that starts with a description of what needs to be deployed, rather than with a prescription of the steps that need to be taken for the deployment. In TOSCA, this description consists of a service model that contains the components that make up the service (TOSCA nodes) as well as the relationships between these components. It is this service modeling functionality that invites comparisons with YANG.

However, this is not an apples-to-apples comparison, since unlike YANG models, TOSCA models carry service semantics: the language includes constructs such as nodes, relationships, requirements, and capabilities, and it uses these constructs to build service topologies. While TOSCA also includes general-purpose data modeling capabilities that are similar to YANG, its main contribution is in its focus on service modeling as well as on the associated service management functionality. Specifically:

• TOSCA services and their components have life-cycle management interfaces that define operations for creating, configuring, deploying, and decommissioning services. TOSCA has built-in implementations for these operations for a number of “primitive” node and relationship types but service designers can provide their own implementations or create custom life-cycle interfaces.
• TOSCA implements a standard workflow for deploying services using the operations of standard life-cycle interfaces, but service designers can also create their own custom workflows.
• TOSCA allows service designers to specify policies with which their services have to comply. This policy support can be used to as a framework for enabling intent-based interfaces. 
• TOSCA supports service templates that can be used as blueprints for instantiating new services.  

It is these service management features that make TOSCA a service automation language rather than just a modeling language. This doesn’t imply that TOSCA is better than YANG, just that it serves a different purpose. In fact, there is plenty of room for both standards and it makes perfect sense to use YANG in the context of TOSCA. For example, when providing implementations for life-cycle management operations for network nodes, TOSCA could translate node properties and attributes into the corresponding YANG configuration data that are then applied to the physical devices using NETCONF-based tools. I’d love to see these types of ideas implemented so we can start focusing on the synergies between TOSCA and YANG and benefit from both.