Don’t Miss the “Cloud Native Infographic” !

Everything is cloud Native from 5G core to RAN, transport and orchestration. Either you know about it or Nothing about Cloud. In this “FREE” one page infographic poster, I have made it a QUICK and EASY reference for Cloud Native main concepts which are otherwise very complex to understand. Plus get notified when important blogs are published.

Cloud Native Infographic

Don’t Miss the “Cloud Native Infographic” !

Everything is cloud Native from 5G core to RAN, transport and orchestration. Either you know about it or Nothing about Cloud. In this “FREE” one page infographic poster, I have made it a QUICK and EASY reference for Cloud Native main concepts which are otherwise very complex to understand. Plus get notified when important blogs are published.

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.

clip_image001

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.

clip_image002

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 .

clip_image003

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.

30 thoughts on “NETCONF/YANG and TOSCA- Friends or Enemies ?”

  1. 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.

    Best regards,
    Carlo

    1. 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)

      1. Hi Faisal,

        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.

        Best Regards,
        Carlo

        1. 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.

          1. Thanks Sri for commenting.

            I agree with you. Infact TOSCA is not a Swiss knife of orchestration.

  2. 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.

    Your blogs are clear and the diagrams are very helpful.

    BTW – I thank Carlo for starting a discussion.

    Regards,
    Michael

    1. Hi Michael,

      Thank you so much for giving your thoughts. I agree with you ..you have good pointers for future blog on the topic of acceptance of TOSCA

  3. 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.

    Regards

    Ansar

  4. 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.

  5. Great sharing, Faisal…thanks for that.

    From your diagram, the NETCONF is direct between OSS and VNF. So, can I say that the NETCONF is not used by VNFM to configure the VNFs, but for the traditional OSS system to configure the VNFs?

    Are there many VNFs supporting NETCONF? I came across some VNFs not supporting NETCONF, but only provide RESTapi to configure the VNFs.

    1. @ 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.

  6. Pankaj Thareja

    Hello Faisal,

    The article is very clear and informative. It is very easy to understand the concepts .

    I will appreciate if you can post an article integrating SDN controller in MANO , explaining different interfaces and provisioning of services .And that is in your language :).

  7. Rajesh R. Bhosale

    Excellent and Articulate article on complex jargons on SDN/NFV 🙂
    Keep posting Faisal!!!

  8. 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.

    1. If you want to scale the size of VNF, you will always have it defined in the VNF descriptor, however if you want to configure VPNs etc, you will use NETCONF and YANG. So both have different scope

Leave a Comment

Your email address will not be published. Required fields are marked *