NETCONF: Introduction To An Emerging Networking Standard

Standards bodies like the IETF have been responsible for introducing innovative new protocols and methods for vendor-agnostic deployment. Some of the most well-known protocol definitions that have gone on to become network staples include IKE and IPsec, RADIUS, and of course routing protocols and applications.

In this article, I will examine an emerging industry standard that plays an important role in the SDN space: Network Configuration Protocol (NETCONF).

Originally published as RFC 4741 in 2006, NETCONF is positioned as a standardized method for network device configuration. Network devices can typically be configured using a vendor-specific CLI. NETCONF provides a programmatic interface to a network device, eliminating the need for users to understand proprietary CLI syntax for device configuration or managing operational data. It leverages the ability to separate configuration data from operational data and statistics (state data) from a device by providing operations for the retrieval of both data types.

This differs from SNMP, which uses a single get operation to pull all data from a device, leaving it up to the user to sort through a plethora of management information base (MIB) variables. SNMP has also been used traditionally for performance and monitoring rather than device configuration.

The transport used by NETCONF is TCP based and ties in to security protocols like SSHv2 and TLS. This compares with SNMP and its use of best effort UDP and no standard security mechanism.

The NETCONF protocol is built on a four-layer approach:

1)      Secure Transport Layer: Authentication and integrity can be provided by protocols such as TCP-based TLS and SSHv2.

2)      Message Layer: A set of RPC messages and notifications are defined for use including , and .

3)      Operations Layer: Defines a set of base protocol operations invoked by RPC methods using XML-encoding. These include , and .

4)      Content Layer: NETCONF data models and protocol operations use the YANG modeling language (RFC 6020). A data model outlines the structure, semantics and syntax of the data.

Here is a simple NETCONF example:

Configuration data is carried inside a element and conforms to the data model identified by the namespace referenced in the RPC message.

XML subtree filtering is used to build the selection criteria to be enforced within an operation to be carried via the RPC message.

Set the maximum transmission unit (MTU) to 1500 on an interface named "Ethernet0/0" in the running configuration:

               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">                                                                                    Ethernet0/0               1500                                             

Acknowledge the operation:

               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">            

NETCONF is supplemented by some key operational capabilities, such as support for rollback and confirmed commit and validation of configurations.

In terms of SDN, NETCONF is often referenced as a southbound API from an SDN controller to network agents like switches and routers due to its potential for supporting multi-vendor environments.

NETCONF and its role in SDN will become even more interesting with the recent announcement of Cisco’s plan to acquire Tail-f Systems. Tail-f’s ConfD uses NETCONF and YANG modeling language to provide SDN-ready configuration and operational data management as well as supporting multi-vendor on-device management, although how Cisco maintains Tail-f's level of vendor neutrality will be interesting to watch. 

More information about NETCONF from a protocol and standards perspective is available on the NETCONF wiki.