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.

Can NETCONF and YANG save from network disasters ?

  •  In April 2002, a nationwide disruption hit AT&T that lasted 3 hours because of the misconfiguration of OSPF in a backbone router.
  • In February 2009, a misconfigured router from SuproNet, a Czech ISP, caused internet services outages worldwide.
  • In 2014, a misconfigured router in China affects 618 Million internet users for 8 hours.

All above are cases of misconfiguration. There may be many more…

Many of them undocumented.

In each case, the operator lost not only business but goodwill and reputation.

So what could be the reason here:

Even though, they are big name operators, who are supposed to have better processes to avoid such disasters.

Yet, when human deal with machines, there are  bound to be human errors.

When there is MORE human involvement, there are more errors.

And this could be the cause of all these disasters.

In fact, there is a lot of human interaction with the networks’  today in terms of configurations ( as they were in the past).

And such disasters may continue to happen because of “continued misconfigurations” if we did not learn the lesson.

Indeed, the need to have better network configuration tool is not new.In 2002, leading operators and industry leaders gathered to voice a need for efficient network configuration tool.

These initiatives led to RFC 3535 in 2003.

Through this RFC, the operators expressed the issues with SNMP and CLI (and other legacy protocols). Additionally, they outlined the need for an efficient and standard based protocol for configuring network. It expressed its desire to move out of “box by box” configuration model to a better and automatic “network configuration” model. A model that would need less human involvement !

So what are the issues with SNMP and CLI?

SNMP is an old and common management protocol. It has proved to be very efficient for monitoring and alarm management.

Yet, it is not purpose-built for configuring network. More specifically

  • SNMP lacks standard MIBs for configuring networks. That is why, vendors have developed a lot of proprietary MIBs which become barrier to managing cross vendor platforms.
  • SNMP is not efficient to  play back configurations; as a query can pull both configuration and monitoring/alarm data from network element. So it is cumbersome for user has to sort one data from the other.
  • It is not fast either. For example, when returning routing tables, it is very slow.

It is these drawbacks of SNMP, which led to widespread adoption of CLI (Command Line Interface), that is faster way of configuring networks. Yet CLI has problems of its own:

  • It is vendor proprietary which makes cross management of platforms  very difficult. This also means that engineers trained on one CLI need to either learn the CLI of the other vendor or the operator has to keep multiple trained and highly qualified engineers thus increasing his OPEX.
  • CLI focuses on box by box configuration, so it involves a lot of human involvement to enter commands so it is error prone and sometimes troubleshooting can take hours to solve apparently trivial issue.

What can NETCONF and YANG do that SNMP and CLI cannot?

The RFC 3535 followed with the formation of NETCONF working group in IETF that led to several RFCs related to NETCONF and YANG overcoming limitations of SNMP and CLI.

The single focus of NETCONF and YANG is “configuration” as they are purpose-built for configuration.

NETCONF and YANG shifts the focus from “box configuration” to “network configuration”

NETCONG is an XML based standard protocol for configuring network elements. It has native “get config” command which returns only configuration data (compare this with SNMP).

The biggest differentiator of NETCONF against the legacy protocols is its ability to support transaction.

What does transaction mean?

To clarify this important concept: take an example of an IPTV service that requires configuring one router, two switches, two firewalls and a billing system.  A transactional protocol   enables configurations on all involved network elements or NONE. This has advantage because if there is any problem of configuration validation on even one network element, the configuration would fail on all the other network elements.  This means there would be no partial “unimplemented configurations” on network elements. As it is clear that transaction focuses on network and not single box configuration.

YANG, on the other hand is a modeling language.  Think of YANG as similar to standard MIBs in the SNMP.  When standard YANG data models, it is very easy for the configuration protocol ( like NETCONF) to configure box of any vendor as the data fields in YANG are similar for all vendors.

So it is very important that NETCONF and YANG are implemented together. Implementing NETCONF alone would not achieve a  lot of benefits if there are no standard models as YANG provides.

 Can NETCONF and YANG save configuration disasters?

NETCONF and YANG can definitely save configuration disasters.

It is clear that together NETCONF and YANG :

  1. Eliminate box by box configuration which is cumbersome and leads to errors thus effectively reducing human errors.
  2. Are transactional that facilitates network wide complex configurations with the peace of mind that configuration would be validated network wide and there is no danger of “unimplemented configurations” in the network if the configuration fails.
  3. Simplify Network configuration as they are standard protocols; thus enable management by any third party Network Management system to manage a network of many vendors.
  4. Engineers trained on one vendor box can understand another vendor’s box as configuration is similar. This means less risks of interoperability issues because of connecting two vendors.

NETCONF/YANG and its relation to NFV/SDN

NETCONF is already supported as one of the south bound protocols in Opendaylight controller. Therefore investment in NETCONF  means that future integration with SDN controller would be easier.

For  NFV, automation and standardization are key elements. Therefore NETCONF/YANG can play a definite role here.  ETSI MANO is a model proposed by ETSI on how different management blocks would interact. However ETSI MANO is still in its early phase. The low level protocols interconnecting different blocks are yet to be defined.

Some industry players have proposed to use NETCONF  as a protocol to configure VNF instances once they are on boarded on the cloud. As such they can be used to support TOSCA which is proposed for deploying VNF in cloud infrastructure.

Concluding Message

I want to leave this blog with a message to make it a point to include NETCONF and YANG as part of your future discussion with your vendor. Include it as part of your RFP /RFI. Ask them to include it in their roadmap. The vendors are already working on it but this would mean a further push to speed up their roadmaps.

I leave below with a few important RFCs which you may include as part of your next RFPs. Do leave me comment in the comment sections below on what do you view as issues with configuration and Can NETCONF and YANG solve them?

RFC 6241

Network Configuration Protocol (NETCONF)

RFC 6242

Defines the NETCONF-over-SSH transport mapping.

RFC 5539

NETCON. Over Transport layer security (TLS)

RFC 6020

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF notifications.

RFC 6021

This document introduces a collection of common data types to be used with the YANG data modeling language.

36 thoughts on “Can NETCONF and YANG save from network disasters ?”

  1. Excellent analysis. Any thoughts on how is it going to impact the Provisioning and Activation layer of Service Provider OSS.

    1. Hi Chandra,

      thanks, actually as NETCONF/YANG relate to network configuration, therefore, are good candidates for provisioning and activation through OSS. The beauty of NETCONF/YANG would be, using it centrally through NMS or OSS.

  2. Thank you for the article,

    Really curious to see how wellYANG/netconf will be dealing with very asics specific things like qos across different vendors.

  3. Nice article.

    However a simple question that if this is such a nice protocol then why we don’t see it being deployed even in mature networks.

    1. Thanks Abdul Aziz Khan,

      While NETCONF is not new, YANG is a relatively newer model. There are many reasons why they are not deployed. One, vendors don’t have it in all of their products. Latest products are supporting them. Two, there is little interest for the vendor in having NETCONF/YANG in legacy products which are deployed in mature networks as it is big developmental work for vendors with little gain. Third, we as operators have done little in pushing and driving our vendors’s roadmaps. Last but not the least, the vendors have done very great job, deliberately or otherwise, in creating a great skilled pool of CLI experts that can run their proprietary codes and are readily available in the job market.

      1. So in a nutshell we can say that as the idea is in its infancy hence it will take some time, I believe it is with all new things not even the technology and the survival is for the fittest 🙂

  4. YANG is a modeling language describing NETCONF message structure. A such it does not have the capability to prevent network misconfiguration. Many misconfigs comes from semantics errors. There has to be robust logic driving network configuration, This logic is the emiter of NETCONF messages. But in case of logic bug, those messages will contain wrong data which can result in network misconfiguration as well. With NETCONF, network service developer life is easier in terms of data types and constraints but itself is no guarantee of misconfigs. With solid bussiness logic and some sanity CLI can provide level of robustness as well.

    1. Thanks Robert for stopping by and commenting. The point of the article is to have less people touching the network that could lead to human errors. and having people that can run and operate multi-vendor networks. Of course there will still be a need of good process and knowledge and I agree that NETCONF and YANG are itself not a guarantee that everything will work. On the other hand, CLI is cumbersome and becomes headache for operators in terms of OPEX when we see how many skilled people are needed for each vendor type. Running interoperability tests/PoCs in multi vendor environment can become nightmare and can block the service velocity needed for today’s programmable networks.

  5. Hello Faisal,
    Excellent article. Keep post!
    Fewer provisioning steps and automation will lead to fewer misconfigurations.
    Best wishes,

  6. Can we use netconf or yang for validations of protocol? For example check if ospf is up or routes are learnt or say FIB is updated.

  7. Great primer Faisal!
    Is there any data from any operator to show that Netconf/YANG has replaced the legacy SNMP/CLI and they see productivity increase of X% or misconfig reduction of Y% ?

    1. Thanks Javal,
      It is still an emerging field. My view is that CLI will still be used in parallel to NETCONF/YANG till the vendor supports complete configuration with NETCONF/YANG. Every vendor is actively working on this.

  8. i think the best way to prevent human error on operating a network is to simplify how to operate the network. there should be new protocols in the future to achieve that better.

    1. Hello Hadi,

      Thanks for visiting the blog ! This is the point of the blog, to make configuration easier and standardized !

  9. Thanks Faisal for such a good discription about NetConf and Yang .
    your remark on trnsaction is very good .. still thinking how it could be possible to mainrain a single transaction with different kind of network elements.
    can u share some more Links about netconf and yang.

  10. Is situation of netconf/yang is different from situation with SNMP given below?:

    SNMP lacks standard MIBs for configuring networks. That is why, vendors have developed a lot of proprietary MIBs which become barrier to managing cross vendor platforms.

    I think not, since datamodels of YANG are propitiatory as well. Only six were standardized. So what are advantages of having equipment of different vendors in the network with propitiatory data-models?

    What if you make mistakes in datamodels? you will get you equipment misconfigured as well.

    1. Hi e3eridani, As NETCONF is transactional, so structured error/mistakes management is much easier compared to CLI. On the part of YANG, I agree with you that the pace of standards is not very encouraging.

  11. Hi Faisal,

    Nice article le, got to learn slot many new things.

    I am new to netconf yang , want to know how netconf is used in configuring, let’s say, 10 network devices simultaneously. How it open connection with them all.


Leave a Comment

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