Can NETCONF and YANG shift the management paradigm from configuring individual devices to the configuration of entire networks?

Which network and service equipment is most likely to incorporate a NETCONF server?

Early adopters of NETCONF include two large router companies. Juniper has led the charge by incorporating NETCONF across its entire product line, while cisco is actively working toward incorporating NETCONF into its product line.

Other early adopters include Tail-f Systems, SNMP Research International, InterWorking Labs and EmbeddedMIND.  These companies offer NETCONF software development tool kits.

Both the TeleManagement Forum and the Metro Ethernet Forum have expressed an interest in considering YANG as a schema definition language for data models used for managing carrier grade communications equipment.

Within the IETF, the IP Flow Information Export (ipfix) working group is using YANG to  create a configuration data model for IPFIX and PSAMP.

Characteristic Strengths

What are the characteristic strengths of NETCONF and YANG that are likely to be attractive to vendors and operators of networks and services?

From my perspective characteristic strengths include:

• the ability to add NETCONF operations to suit operational requirements
• the capacity for NETCONF to perform well at a frequency of configuration changes that exceeds human ability via CLI or Web form
• the ability of YANG to provide excellent support for complex data models and namespaces
• the design of YANG enables data models to grow over time via augmentation and extension
• the use of the XPATH filtering mechanism supports efficient use of network bandwidth

And the key aspect to keep in mind is that YANG provides a concise language for data modelling that overcomes the limitations of XSD and that YANG modules are fully mappable to equivalent RELAX NG.

Characteristic Weaknesses

What are the characteristic weaknesses of NETCONF and YANG that are likely to be unattractive to vendors and operators of networks and services?

From my perspective characteristic weaknesses include:

• YANG is ‘overkill’ for simpler, less sophisticated network equipment and services
• YANG lacks a robust configuration object lifecycle model
• An appropriate approach towards authorization remain a work-in-progress for NETCONF and YANG
• Compared to XSD, YANG has little support for schema creation and editing and for validation of instance documents
• NETCONF does not scale well for frequent configuration of 1000s of devices due to the overhead of establishing TCP connections and SSH sessions

Potential Application Realms

What are the potential application realms for NETCONF and YANG?

Given the above characteristic strengths and weakness, NETCONF and YANG are potentially attractive in realms that include:

• Smart grid
• Multi-tenant managed IT services
• Cloud computing and data centers
• Carrier grade telecommunications and internetworking equipment

NETCONF and YANG are probably not attractive solution for simpler, low end network devices, single user computing systems and web applications designed for SOHO environments.

Summary

NETCONF and YANG are well suited for advanced configuration management of complex networks and services.  These technologies have an interesting market potential and stake holders are working towards raising the visibility of NETCONF and YANG within the communication and computing industries.

The degree to which these technologies are embraced by the market will depend upon the perception that YANG is a superior data modelling language.

Early adopters have already integrated NETCONF and YANG into products.  Ultimately, the degree of success enjoyed by NETCONF and YANG will be determined by the rate and level of adoption within potential markets.

This article is part of a series of articles. To view other articles in this series please follow the NETCONF and YANG tag.

Introduction

The Network Configuration (NETCONF) protocol is designed as a simple mechanism through which the configuration data residing on a network device may be inspected and manipulated. The NETCONF protocol uses the abstraction of operations with parameters to facilitate the development of applications for configuration management of network devices.

Within the NETCONF architecture, there exist two peer roles: the NETCONF client and the NETCONF server.

The client role is fulfilled by a person or a management application.  The client is responsible for the configuration management of some number of network devices.  The server role is fulfilled by software residing on a network device.  The server is responsible for the exchange of NETCONF messages and for the orderly manipulation of local configuration data.

In order to exchange NETCONF messages, a client must first establish a NETCONF session with a server.  When a session is established, each NETCONF peer exchanges a list of its capabilities with the other peer.

A NETCONF capability is represented by a uniform resource name (URN).  Each capability corresponds to a set of features supported by a NETCONF peer.  A feature may provide support for an RPC operation or specify the semantics for parameters associated with an RPC operation.

The concept of capabilities is a powerful tool and enables the extensibility of the NETCONF protocol.  The base NETCONF capability is the minimum set of features each a NETCONF peer must implement, represented as “urn:ietf:params:netconf:base:1.0″.

NETCONF Protocol Layers

The NETCONF protocol can be conceptually partitioned into four layers.

Messages exchanged on a NETCONF session between a client and server pass through each layer.  We discuss the purpose of each layer within the NETCONF protocol in the following sections.

The Transport Protocol Layer

The transport protocol layer provides an end-to-end network connection for the exchange of messages between a client and a server.  Section 2 of RFC 4741 discusses requirements of the transport protocol layer.

The transport protocol provides the following features:

• indicates the session type: client or server
• connections are persistent, durable and stateful
• reliably delivers an ordered sequence of messages
• releases resources associated with a session when its connection terminates
• responsible for user authentication

A NETCONF implementation must support the SSH transport protocol mapping.  The NETCONF mapping for SSH is specified in RFC 4742.  Optional transport mappings include console shell, and TLS (RFC 5539).

The RPC Layer

Tje RPC layer provides a communication model for framing NETCONF requests and responses. Section 4 of RFC 4741 discusses requirements of the RPC layer.

NETCONF requests use an <rpc> element and NETCONF replies use an <rpc-reply> element.  The <rpc> element within a NETCONF request contains a mandatory “message-id” attribute and may contain any optional attributes useful to the client.  The “message-id” attribute facilitates the correlation of a request with its response.  The <rpc-reply> element of a NETCONF response always contains an unmodified copy of the set of attributes present in the <rpc> element of the corresponding NETCONF request.

The RPC operation name and its parameters are encoded as the content within the <rpc> element.

When the result of an RPC operation contains errors, one or more <rpc-error> elements are present within the <rpc-reply> element of the response.  Each <rpc-error> element describes an error encountered during processing of the RPC operation.  When the result of an RPC operation is free of error, an <ok> element is present within the <rpc-reply> element of the response.

Once a NETCONF session is established, a client may send multiple requests to the server without waiting for a reply.  A NETCONF server responds to each request in the order it was received.

The Operations Layer

The operations layer provides a mechanism for the proper handling of NETCONF operations present within requests and for the proper handling of reply content present within responses.  Section 7 of RFC 4741 discusses requirements of the operations layer.

The NETCONF protocol base capability defines a small set of operations and associated parameters for the inspection and manipulation of configuration data.  The NETCONF protocol base capability is extensible.  A client or server that supports additional operations or parameters will advertise its extensions in its capabilities exchange when establishing a NETCONF session.

Each <rpc> element in a request contains a NETCONF operation name and an associated set of XML-encoded parameters. The following table summarizes the set of operations in the NETCONF protocol base capability.

We will revisit NETCONF operations and associated parameters in a future article.

The Content Layer

The content layer provides the NETCONF protocol with a mechanism for encapsulating configuration data. Section 5 of RFC 4741 discusses requirements of the content layer.

Configuration data associated with a NETCONF operation is XML-encoded within a <config> element.  On a network device,  configuration data resides within a configuration datastore.

Proper configuration data is constrained by the semantics of the YANG schema defined for a network device.  The YANG data modeling language, currently a work-in-progress of the IETF NETMOD working group, was created primarily to address the needs of modeling the configuration and state data conveyed by the NETCONF protocol.

A YANG schema defines a set of data nodes organized as a hierarchical tree.  Each data node in the tree has a name and either a value or a set of child nodes.  YANG schema are structured into modules and submodules that  may be published by a standards organization, an enterprise or an industry forum.

A key design feature of YANG is its support for modular extensibility.  One YANG module may define additional data nodes augmenting the data nodes defined in another YANG module.

Since configuration data is specific to the data model of a network device, the NETCONF protocol does not inspect or manipulate configuration data.  The set of YANG modules defining the schema of a network device is identified within the list of capabilities sent by its server to a client when a NETCONF session is established.

The NETCONF client can subsequently retrieve and inspect the YANG schema for a network device to gain an understanding of the layout, containment, keying and other semantic constraints imposed upon the configuration and state data exchanged with a NETCONF server.  Note that the schema for a network device can be fully mapped from YANG to other XML based schema languages, such as DSDL to facilitate validation tasks.

The <get> and <get-config> NETCONF operations support subtree filtering when a <filter> element is present.  Subtree filtering enables a client to limit the data returned by a server to the set of subtrees matching the filter expression.

There are five types of components that may be present in a subtree filter:

• Namespace Selection
• Attribute Match Expressions
• Containment Nodes
• Selection Nodes
• Content Match Nodes

An optional extension allows filters to use XPATH expressions.

Using the YANG data modeling language to create schema and using the NETCONF subtree filtering mechanisms to match portions of the schema tree are interesting topics that we will revisit in future articles.

This article is part of a series of articles. To view other articles in this series please follow the NETCONF and YANG tag.

MOTIVATION:

Over the past two decades, some significant issues emerged relative to the current best practices for the configuration of networks and services:

Using SNMP as the basis for configuration tasks for the many network devices sold by communications equipment vendors became rather complicated.  Most MIB modules published by the IETF proved useful for monitoring purposes. However, for configuration tasks, vendors chose expedience over interoperability by implementing their own private enterprise MIB modules instead of working with peer vendors to define a common set of configuration objects for similar communications devices.

Further more, the semantics of the CLI across communications devices from multiple vendors lacked uniformity and lacked stability.  Vendors’ methods for session establishment and user authentication needed by configuration tasks varied.  The format and content of configuration data as well as error values and their meanings differed across vendors’ products.  Sometimes semantic changes were encountered within the CLI across revisions of a single vendor’s product.

Using the HTTP and web-based forms encountered issues similar to those found with the CLI.

Such realizations evolved into a set of known issues and gained mind share during discussions between network operators and participants within the IETF.

What could be done to reduce the complexity of operator tasks associated with the configuration of networks and services?  Did participants think this work was feasible?  Who would propose and how would standards be developed for the configuration of networks and services?

Inception:

The feasibility of the Network Configuration (NETCONF) protocol was initially discussed at IETF 56 in San Francisco during March of 2003.

Participants discussed the known issues in the configuration of networks and services and discussed the set of requirements solicited from network operators and protocol developers, as described in RFC3535 , “Overview of the 2002 Network Management Workshop”.

Based upon a rough consensus achieved during these initial discussions, a new IETF working group was convened within the Operations and Management area.  The full charter for the working group, is provided on the NETCONF web page.

The NETCONF working group charter provides key aspects for the protocol design as follow:

• Provides retrieval mechanisms which can differentiate between
  configuration data and non-configuration data
• Is extensible enough so that vendors will provide access to all
  configuration data on a device using a single protocol
• Has a programmatic interface (avoids screen scraping and
  formatting-related changes between releases)
• Uses a textual data representation, that can be easily manipulated
  using non-specialized text manipulation tools
• Supports integration with existing user authentication methods
• Supports integration with existing configuration database systems
• Supports network wide configuration transactions (with features such
  as locking and rollback capability)
• Is as transport-independent as possible
• Provides support for asynchronous notifications

In addition to the key aspects above, the NETCONF charter specifies the use of XML for data encoding purposes, because XML is “a widely deployed standard supported by a large number of applications”.

And significantly for YANG, The NETCONF charter states that the data modeling language for describing configuration and state data should remain independent of the NETCONF protocol.  This NETCONF requirement provided the impetus for the eventual creation of the NETCONF Data Modeling Language (NETMOD) working group, with informal discussions during IETF 70 in Vancouver in December of 2007.

To focus emerging NETMOD discussions, an internet draft on the Requirements for a Configuration Data Modeling Language (draft-presuhn-rcdml) was prepared and a charter established.

The NETMOD working group charter provides key aspects for the data modeling language as follow:

• Designs a “human-friendly” modeling language with a focus upon readability and ease of use
• Has semantics for defining:
  
  • Operational data
  • Configuration data
  • Notifications
  • Operations

• Uses YANG (draft-bjorklund-netconf-yang) as the starting point
• Defines standard mapping rules from YANG to the ISO/IEC 19757 Document Schema Definition Languages (DSDL) data modeling framework with additional annotations to preserve semantics
• Consults with the NETCONF working group so that decisions do not conflict with NETCONF work

Since the pool of participants in the NETCONF and NETMOD working groups overlap to a significant degree, consulting on the implication and potential conflict of decisions would appear to be easily handled.

Summary:

Work on the NETCONF protocol and YANG data modeling language came about due to the realized short comings of using the SNMP, the CLI, and the HTTP and web-based forms as the basis of a consistent and stable mechanism for the configuration of networks and services.

Standards work on the first version of the IETF NETCONF protocol commenced in 2003. This work is currently nearing completion with seven published RFCs and four work-in-progress Internet-Drafts.

Standards work on the YANG data modeling language commenced in 2008. This work is currently proceeding within the IETF NETMOD working group with five work-in-progress Internet-Drafts related to YANG under technical review and discussion.

In our next article, we gain an understanding of the architecture of the NETCONF protocol.

This article is part of a series of articles. To view other articles in this series please follow the NETCONF and YANG tag.

Over the past several years, participants within the IETF Operations and Management area have published two complementary series of RFCs that specify a proposed standard for the advanced configuration of networks and services.

The first series of RFCs specify the protocol operations (NETCONF) for manipulating configuration data and examining state information contained within network devices and services.

The second series of RFCs specify the schema language (YANG) for defining the XML-based configuration data transported by NETCONF.

Together, NETCONF and YANG provide operators and vendors a standards based alternative to relying upon the varied semantics encountered when using some combination of CLI, SNMP and HTML based configuration applications.

Our technical overview is comprised of a number of topics exploring some interesting aspects of the design and features found within NETCONF and YANG.  Topics are each presented in a separate article and include:

• Motivation and Inception: What were the reasons for this standards work?  When and how did work start on these standards?
• Architecture:  What is the organization of the design features and fundamental components found in NETCONF and YANG?
• Potential Markets:  What portions of the IT industry are most likely to incorporate NETCONF and YANG technology into their management approach?
• Basic Terms and Concepts: What are the basic terms and concepts within NETCONF and YANG?  What are the relationships among concepts?
• Operations:  Which operations are part of the base set of capabilities?  How is the set of basic operations extended?
• Capabilities:  What are NETCONF and YANG capabilities.  Why are capabilities important?
• Configuration Schema:  Why was a new language defined for creating schema for the data modelling of configuration data?
• Data Modelling: How do I use YANG to create a schema for my configuration data?
• Data Modelling: How do I use YANG to extend and augment another data model?

This article is part of a series of articles. To view other articles in this series please follow the NETCONF and YANG tag.

Versions of the SNMP prior to third version (SNMPv3) did not include adequate security. Any sufficiently motivated individual with physical access to a shared network link and a protocol sniffer had the ability to capture clear text messages exchanged between a manager application and its agents. Once captured, it was simply a matter of extracting community strings and agent addresses of interest in order to usurp the role of the manager application, possibly hijacking and re-configuring network devices along the way.

The design of SNMPv3 included authentication and privacy (encryption) mechanisms for the protocol. By incorporating these mechanisms, SNMPv3 became self sufficient with no need of any other network services for the secure transmission of SNMP messages. After all, network operators need their network management protocol to be functional even when major portions of the network and its services are impaired.

Three security levels are defined for SNMPv3, in increasing degree of security as follow:

• noAuthNoPriv – essentially clear text messages providing backwards compatibility with earlier versions of the SNMP
• authNoPriv – authenticated messages (SHA1 or MD5 hash), but messages are still transmitted in clear text
• authPriv – authenticated messages with the scoped PDU portion of message encrypted (DES or AES)

For manager applications that only require their agents to verify the authenticity of SNMP message exchanges, the authNoPriv security level is sufficient. This security level offers adequate protection for SNMP message exchanges that do not include sensitive data.

For manager applications that require their agents to both verify the authenticity of SNMP message exchanges and to provide privacy (encryption) of sensitive data contained within the scoped PDU portion of the SNMP message, the authPriv security level must be used. Since the DES encryption cipher is considered cracked, an AES encryption cipher of sufficient length should be used.

However, it is important to avoid using weak authentication or privacy pass phrases. Even when an SNMP manager application uses the authPriv security level with the AES cipher, you can jeopardize secure SNMPv3 message transmissions. In better deployments, the SNMP configuration and applications work together with the proper ciphers and strong pass phrases to ensure secure SNMPv3 message transmission and I am happy to show you just how easy it is to get this right.

In highly secure environments snmpEngineID values should also be protected by using a discovery mechanism together with a security model that avoids exchanging cleartext SNMP messages on network links.

The next step towards using SNMPv3 for secure transmission of SNMP messages is to contact me with your project requirements and questions.