Understanding NETCONF and YANG

This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.

Service provider and enterprise network teams that are moving towards a service oriented approach to network management are reaching for the IETF's Network Configuration Protocol (NETCONF) and YANG, a data modeling language, to help remove the time, cost and manual steps involved in network element configuration.

NETCONF is the standard for installing, manipulating and deleting configuration of network devices while YANG is used to model both conguration and state data of network elements. YANG structures the data definitions into tree structures and provides many modeling features, including an extensible type system, formal separation of state and configuration data and a variety of syntactic and semantic constraints. YANG data denitions are contained in modules and provide a strong set of features for extensibility and reuse.

What does this mean? Network automation is currently blocked by current approaches where you need to write device specific CLI scripts or are locked into rigid closed tools. There is nothing wrong with CLIs; they are perfect for humans, but less optimal for software. NETCONF is defined for transaction-safe configuration of devices. This means that scenarios like setting up initial configuration for a range of devices, changing ACLs and adding VPNs, can be performed automatically, while keeping flexibility and vendor independence.

Additionally, time-to-market requirements in delivering new services are critical and any delay in conguring the corresponding devices directly affects deployment and can have a big impact on revenue. Organizations are seeing the need to get the people out of the way to automate the configuration and implementation of network devices.

Ultimately the technology is designed to support more robust management of configuration, including configuration change transactions including rollbacks, strong separation between configuration and state data allowing for efficient backup-and-restore, selective data retrieval with filtering using well-known query mechanisms and streaming and playback of event notifications.

The current scale of networking across service providers, enterprises and cloud providers poses unprecedented challenges to operations teams. As both frequency and complexity of changes made to the network, as well as the cost of failed configurations explode, network operations teams understand the cost savings that come with delivering services quickly and are now requiring the use of NETCONF and YANG in their environments to achieve these benefits. Compound this with all the other challenges organizations face -- including frequent network changes, service agility, network complexity, SLAs becoming tighter and simply doing more with less -- it is no wonder networking teams are losing sleep.

With the network industry being quite conservative; there are a couple of things that need to happen for any management technology to take hold:

" First, the technology needs to be implemented in mainstream network products. This means that support for the NETCONF protocol needs to be included with versions of router and switch operating systems like JunOS from Juniper and IOS-XR from Cisco." Second, there needs to be support for the technology in software used by operations teams that run the network. This may include command line tools for network engineers that can troubleshoot issues all the way up to the top while supporting the provisioning and orchestration parts of the OSS/BSS stack." Finally, and most importantly the main driver of implementation and adoption for both items is directly related to whether end-users are asking for it. Unless technologies like NETCONF are explicitly named in RFIs and RFQs, there is little incentive for the vendors to implement it.

Interoperability testing of devices

Looking back at what we learned with SNMP, one of the challenges around standards is get beyond simply ticking off compliance in an RFP and actually supporting the standard according to the RFCs. In many cases users of technology suffer from non-conformant implementations. If vendors just put their CLI config within NETCONF tags nothing is gained.

For NETCONF and YANG, this has happened in a slightly different order. Some of the equipment providers (e.g. Cisco, Juniper, Ericsson) showed the way by providing strategic early implementations of NETCONF (in contrast to customer-driven).

The next second step in the process is happening right now. Network operations teams are at the point where manual configuration is a non-starter, so there is an urgent need for automation solutions. This is currently driving increased mentions of NETCONF and YANG in RFIs and RFQs. This in turn is drawing quite significant attention from the network management software companies that wants to stay relevant in these areas.

A Word about NFVAdditionally, there has been a lot of interest recently in Network Function Virtualization (NFV). NFV is an emerging operational model where service providers want to leverage the impact that virtualization has had in the server market and replicate that for network applications.

NFV is built around a very strong assumption of deep automation. This ties it directly to NETCONF with its standardized protocols and models, making it possible to deploy multi-vendor virtual network functions. NFV and NETCONF work together to help provide a broader solution to meet the current and growing need to configure and manage multi-vendor devices that are prevalent in the data center.

The future of NETCONF looks bright as more and more organizations take advantage of the cost and time savings to the data center and network management structure. By leveraging NETCONF and YANG in the context of NFV, networking team can focus on the network design and configuration that ultimately makes the most efficient use of the network equipment. Additionally, it provides the ability to make form factor and vendor choices that are not directly tied to the services, but focused on the cost and how well the products perform the specific networking task.

Read more about infrastructure management in Network World's Infrastructure Management section.

Tags managementNetworkinginfrastructure managementNetwork management

More about Cisco Systems AustraliaEricsson AustraliaIETFJuniperSNMP

Comments

Comments are now closed

Symantec donates $260k towards cyberbullying prevention

READ THIS ARTICLE
DO NOT SHOW THIS BOX AGAIN [ x ]