Don't miss the NFV mind map !

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.

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.

Subscribe
Notify of
guest
36 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
praveen
praveen
5 years ago

Dear Faisal ,

Wonderful article , keep posting good thought …

Rajesh Bhosale
Rajesh Bhosale
5 years ago

Clear & concise way to explain NETCONF & YANG!!!
Excellent work Faisal!!! Keep posting ??

Chandra
Chandra
5 years ago

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

Andrea
Andrea
5 years ago

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.
Cheers
Andrea

Abdul Aziz Khan
Abdul Aziz Khan
5 years ago

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.

Abdul Aziz Khan
Abdul Aziz Khan
5 years ago
Reply to  Faisal Khan

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 🙂

Robert
Robert
5 years ago

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.

shivlu jain
5 years ago
Reply to  Robert

Implementing Yang is not as easy as it looks alike. It requires lot of hard work to develop and test the models. I am completely agree with Robert Comment.

Max
Max
5 years ago

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

Sonu
Sonu
5 years ago

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.

shivlu jain
5 years ago

excellent article

asif hussain joo
asif hussain joo
5 years ago

good insights provided, keep posting the articles.

Felipe Alencar
5 years ago

Thank you very much for writing this! Finally I understand what NETCONF/YANG really is. Keep it up!

Javal
Javal
5 years ago

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% ?

hadi
hadi
5 years ago

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.

Aruna Dhammika
Aruna Dhammika
5 years ago

Super writing Faisal. At last i understand NETCONF/YANG basics. Keep writing pl…

Prakash
Prakash
4 years ago

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.

e3eridani
e3eridani
4 years ago

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.

Saloni Aggarwal
Saloni Aggarwal
5 months ago

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.

Thanks,
Saloni

36
0
Would love your thoughts, please comment.x
()
x