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 Orchestrahttps://telcocloudbridge.com/a-beginners-guide-to-nfv-management-orchestration-mano/tor 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:

· Configuring L3 VPN services on demand between the routers or modify existing ones.

· Configure new firewall rule on a router.

· Change QoS configuration.

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.