Well ! I have done all the efforts and made concepts simple through the Free NFV Mind Map. Get it now before I take it off. Plus get free updates to my blog.

NETCONF/YANG and TOSCA- Friends or Enemies ?

NETCONF/YANG vs TOSCA for NFV service orchestration is more of an academic discussion rather than a practical one.

To many, there is a misunderstanding on the exact place where TOSCA should be used vs NETCONF/YANG.

Trying to use one tool to do the other’s job is like fitting a square peg in round hole.

Remove one of them and you have removed all the flexibility of working with NFV in the NETWORKING environment.

And if you are a network engineer dealing with the routers, it is very important to understand the role of the two in order to avoid confusion working with multiple orchestration tools. Also understanding them may help you decide which skills to focus in future.

First, a word about these terms.

NETCONF/YANG targets network configuration- NETCONF is a protocol used for configuration; it uses standard data models which are YANG based. In simple words, you would need the NETCONF protocol to reach a router and then use standard information elements ( YANG) to configure the router. Using standards based protocols like these would enable moving out of vendor-specific CLI and thus achieve cross-vendor compatibility using same configuration tools.

TOSCA (Topology and Orchestration Specification for Cloud Applications), on the other hand, is used in clouds. An application developer captures an application’s operational requirements in a deployment template. This deployment template has everything on how an application will be started , brought to the operational state and modified such as scaled up and down. This deployment template is used by the cloud management system to bring up the App and additionally also establish virtual connectivity between apps ( the orchestration). TOSCA from OASIS standard body is one such standard deployment template.

Of late, Interest in TOSCA has increased, as more and more organizations are favoring using TOSCA as an orchestration tool in NFV environments.

So how do we position TOSCA against NETCONF/YANG in NFV’s context?

To understand that, let’s see where TOSCA fits in ETSI MANO Architecture. ( For refresher on MANO, read here)

See below a diagram of NFV MANO architecture. The encircled block holds repositories in NFV. Two of these repositories are important in this context:

· The VNF ( Virtual Network Function) catalog is the deployment template for a VNF.Using this template, VNF is brought to the operational state. Also, this enables scaling up and down the VNF according to the needs.

· NS ( Network services) catalog. This catalog has all the information about connectivity between different VNFs and thus enables orchestration. To give an example, service chaining between a load balancer and firewall would need the orchestrator to use this catalog.

So we may conclude that TOSCA can be a good fit for use as a deployment template in NFV as it is already a standard way for the same purpose in cloud environment.

In the following example using TOSCA as a deployment template, the Orchestrator using VNFM brought up two virtual routers ( VNFs).They are in the operational state. They have even been chained to one another through a virtual link.

From MANO perspective, TOSCA has already brought up the “service”. In other words , service lifecycle in MANO’s context, means maintaining VNFs in a proper state and stitching them to create network service.

However, from a networking perspective, there are still many runtime configurations that need to be done. TOSCA cannot delete or modify configurations on-demand on the routers it has brought up as it is just a deployment template. Some of the configurations that may need to be done are:

That is where NFV orchestrator would need the help of OSS to do these runtime configurations, as shown below.

And that is where NETCONF/YANG comes into picture as it is perfect and purpose built for network configuration .

There are many who would make us believe that you either need NETCONF/YANG or TOSCA but not both. However,TOSCA is not purpose built for such network configuration. TOSCA is only a deployment template that will bring up a VNF and keep it in operational state.

So, therefore, it makes sense to use NETCONF/YANG and TOSCA complimentary to each other

1. TOSCA to bring up, tear down, scale up and scale down VNFs.

2. NETCONF/YANG to do refined , dynamic and runtime configuration on the already running VNFs.

Using any one of them to do both jobs would need a lot of customizations and further development and may need to reinvent the wheel which is already available.

So why not use NETCONF/YANG and TOSCA as friends rather than enemies ?

Drop me a line below and share your views or ask any question on this topic. I would love to communicate with you.

Reference: The original motivation for this blog came from a webinar of upskill university in which the presenter- Stephen Vallin very nicely explained the positioning of TOSCA versus NETCONF/YANG.

Thanks for the information,just one thing so can we say in tosca template the networking information given what we say as VNF Forwarding Graphs is just one time used by VNFM for churning up the VNF’s and allocating them ip’s and after that if we want to dynamically change the network configuration we have to use netcont/yang for it.

@ KK, thanks , your interpretation is correct. usually NETCONF will be used by OSS or EMS/NMS. Only the VNFs related to networking like routers should support NETCONF, As NETCONF is specifically related to networking. RESTapi is alternative way to configure any VNF including networking VNFs.

Hi Faisal
I was struggling with contextualizing YANG and TOSCA in the Virtualization domain. I did and read up the specifications independently but was very confused. Your article has made the penny drop for me and is at the right level for a Beginner. We are having these discussions within our team on TOSCA v/s YANG or both and this article has really helped in making that distinction. Keep up your good work.

Another excellent, relevant and timely article which attempts to simplify the complexity surrounding some of the variables within orchestration domain. Thanks for sharing the beautifully written article and I agree with the thoughts of utilising TOSCA and NETCONF/YANG model together.

Fiasal – another well thought-out blog, and I also agree that both YANG/(NETCONF, RESTCONF, TR-069, etc.) and TOSCA have a distinct use and can be used concurrently.

I think another interesting blog to follow this one would either be the alternatives (options) to TOSCA or the reasons why there are groups that don’t like TOSCA. We are all making our way through this fledgling field of virtualization and sharing helps everyone – even if there isn’t consensus.

Thanks for sharing. Your articles are always interesting and useful.
I’m like to add my contribution to the topic. I fully agree with the conclusion: TOSCA and YANG can be used concurrently for a better MANO. Just a clarification: TOSCA is A model, while YANG is a model language, so not properly in the same level to be compared. For example, you can use YANG to design TOSCA.
Also it would be probably better to split YANG and NETCONF too. Yes, NETCONF is the most common interface connected to YANG SDK, but it is not the only one.

Thanks Carlo for your insightful comments. Highly appreciated. Just a point though. YANG is a modeling language but what it creates are data models, which are called YANG models. It is these common YANG data models that will enable one vendor to configure the equipment of another vendor using NETCONF. I agree with you that NETCONF is not the only way that makes use of YANG models but it is considered one of the popular way when it comes to configuration in the networking world( the example given in the blog)

correct. My point is that using YANG you can create ANY data model, just as your need, while
TOSCA is A data model, so not flexible at all. But this is a details, not decreasing by a bit the
quality of your articles.

This is it. Also there could be areas (e.g. typical standard deployment of VNF or PNF) TOSCA could be more complicated. End of the day the industry kind of accepted that virtualization is all about flexibility so I doubt TOSCA in its current form can meet the needs of all. It does have a clear play in a cloud environment using templates but may not be in a TELCO DC or Telco environment.