{"id":1171,"date":"2016-06-16T17:20:57","date_gmt":"2016-06-16T14:20:57","guid":{"rendered":"https:\/\/telcocloudbridge.com\/?p=1171"},"modified":"2016-06-16T17:20:57","modified_gmt":"2016-06-16T14:20:57","slug":"netconfyang-and-tosca-friends-or-enemies","status":"publish","type":"post","link":"https:\/\/telecomlighthouse.com\/?p=1171","title":{"rendered":"NETCONF\/YANG and TOSCA- Friends or Enemies ?"},"content":{"rendered":"

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

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

Trying to use one tool to do the other\u2019s\u00a0 job is like fitting a square peg in round hole.<\/p>\n

Remove one of them and you have removed all the flexibility of working with NFV in the NETWORKING environment.<\/p>\n

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\u00a0 future.<\/p>\n

First, a word about these terms.<\/p>\n

NETCONF\/YANG<\/b>\u00a0 targets network configuration- NETCONF is a protocol used for configuration;\u00a0 it uses standard data models which are YANG based. In simple words, you would need\u00a0 the NETCONF protocol to reach a router\u00a0 and then use\u00a0 standard information elements ( YANG)\u00a0 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.<\/p>\n

TOSCA (Topology and Orchestration Specification for Cloud Applications)<\/b>, on the other hand, is used in clouds. An application developer captures an application\u2019s 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<\/a> standard body is one such standard deployment template.<\/p>\n

Of late,\u00a0 Interest in TOSCA has increased, as more and more organizations are favoring using TOSCA as an orchestration tool in NFV environments.<\/p>\n

So how do we position TOSCA against NETCONF\/YANG in NFV\u2019s context?<\/h2>\n

To understand that, let’s see where TOSCA fits in ETSI MANO Architecture. ( For refresher on MANO, read here<\/a>)<\/p>\n

See below a diagram of NFV MANO architecture. The encircled block holds repositories in NFV.\u00a0 Two\u00a0 of these repositories are important in this context:<\/p>\n

\u00b7 The VNF ( Virtual Network Function)\u00a0 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.<\/p>\n

\u00b7 NS<\/a> ( Network services)\u00a0 catalog. This catalog has all the information about\u00a0 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.<\/p>\n

\"clip_image001\"<\/a><\/p>\n

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

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<\/a> ( VNFs).They are in the operational state. They have even been chained to one another through a virtual link.<\/p>\n

\"clip_image002\"<\/a><\/p>\n

From MANO perspective,\u00a0 TOSCA\u00a0 has already brought up the \u201cservice\u201d. In\u00a0 other words , service lifecycle in MANO\u2019s context, means maintaining VNFs in a proper state and stitching them to create network service.<\/p>\n

However, from a networking perspective<\/a>, 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:<\/p>\n

\u00b7 Configuring L3 VPN services on demand between the routers or modify existing ones.<\/p>\n

\u00b7 Configure new firewall rule on a router.<\/p>\n

\u00b7 Change QoS configuration<\/a>.<\/p>\n

That is where NFV orchestrator would need the help of OSS to do these runtime configurations, as shown below.<\/p>\n

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

\"clip_image003\"<\/a><\/p>\n

There are many who would\u00a0 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.<\/p>\n

So, therefore, it makes sense to use NETCONF\/YANG and TOSCA complimentary to each other<\/h2>\n

1. TOSCA to bring up, tear down, scale up and scale down VNFs.<\/p>\n

2. NETCONF\/YANG to do refined , dynamic and runtime configuration on the already running VNFs.<\/p>\n

Using any one of them to do both jobs\u00a0 would need a lot of customizations and further development\u00a0 and may need to reinvent the wheel which is already available.<\/p>\n

So why not use NETCONF\/YANG and TOSCA as friends rather than enemies ?<\/p>\n

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

Reference: The original motivation for this blog came from a webinar of upskill university in which the presenter- Stephen\u00a0 Vallin very nicely explained the positioning of TOSCA versus NETCONF\/YANG.<\/p>\n","protected":false},"excerpt":{"rendered":"

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\u2019s\u00a0 job is like fitting a square peg in round hole. Remove […]<\/p>\n","protected":false},"author":2,"featured_media":1828,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-1171","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sdn"],"_links":{"self":[{"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/posts\/1171","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1171"}],"version-history":[{"count":0,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/posts\/1171\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/media\/1828"}],"wp:attachment":[{"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1171"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1171"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1171"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}