- In April 2002, a nationwide disruption hit AT&T that lasted 3 hours because of 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 :
- Eliminate box by box configuration which is cumbersome and leads to errors thus effectively reducing human errors.
- 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.
- 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.
- 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.
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?
Network Configuration Protocol (NETCONF)
Defines the NETCONF-over-SSH transport mapping.
NETCON. Over Transport layer security (TLS)
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.
This document introduces a collection of common data types to be used with the YANG data modeling language.