The rapid expansion and increasing complexity of networks are rendering traditional methods of managing network devices and resources inadequate. Network environments are evolving into large, dynamic ecosystems that integrate multiple systems and tenants, surpassing the capacity of manual management. These changes demand quick, error-free deployment and configuration capabilities that traditional command-line interfaces (CLI) cannot provide due to their lack of standardization. The growing uniformity in hardware, largely based on similar software stacks, underscores the potential for adopting standardized, coherent data models.
These models facilitate efficient automation and management of complex, large-scale network environments by offering a consistent means of device interaction. As such, the development and adoption of data modeling languages like Yet Another Next Generation (YANG) are crucial for simplifying network management processes in these extensive, dynamic ecosystems.
This article explores YANG’s significance as a data modeling language in network management. By examining its role in the automation and programmability of network functions, the advantages it offers network operators and engineers are highlighted. For a better understanding, it is essential first to provide insight into the subject of data modeling.
Data modeling
In the realm of information systems, data modeling serves as a blueprint for how data is collected, organized, stored and retrieved. Data modeling involves the creation of data models - abstract representations that describe the structure of a database or data system, detailing how data is interconnected, and how it will be manipulated and accessed. Data models are essential for understanding and visualizing the relationships among different data elements, and for systems design.
Data modeling is critical for organizing data so that it can be efficiently queried, updated, and maintained. It lays the groundwork for data storage, retrieval, and management strategies that are optimized for the specific requirements of an application or system.
The principles of data modeling become instrumental in managing the increasingly complex and dynamic nature of modern network infrastructures. In networking, data modeling is applied to represent the structure, management, and operational state of network elements and services. This representation is crucial for automating the configuration, monitoring, and management of network devices and for ensuring interoperability among various systems and devices.
Introduction to YANG
Evolution from SNMP
Simple Network Management Protocol (SNMP), developed in the late 1980s, became the first widely deployed Internet standard for network management. Despite being designed for network device configuration, it was primarily used for monitoring. While effective for defining monitoring parameters it proved to be troublesome and lacked the flexibility needed for more complex network configuration tasks. Furthermore, the unpredictable nature of SNMP's output, with content and formatting subject to change, highlighted its unsuitability for the demands of configuring network equipment.
Conceiving NETCONF
The discussions on SNMP's limitations highlighted the need for a more robust network management protocol, leading to the development of NETCONF by the Internet Engineering Task Force (IETF). NETCONF was engineered with the aim of offering a more structured, secure, and efficient means of configuring network devices, addressing the deficiencies observed in SNMP.
Some of the advantages of NETCONF include:
- Connection-oriented transport: Utilizes TCP for transport, ensuring reliable delivery of messages.
- Security: Utilizes SSH, a fully encrypted protocol, providing enhanced security measures.
- Improved bulk operations: In comparison to SNMP it offers superior performance for bulk data transfers.
- Transactional changes: Supports making configuration changes in a transactional manner, ensuring consistent application across multiple devices.
- Multiple data stores: Provides a 'running' configuration data store, with 'startup' and 'candidate' data stores as optional, facilitating testing and validation of configurations before application.
- Comprehensive configuration transactions: Enables sending an entire device's configuration in a single <edit-config> transaction, streamlining the configuration process.
- Backup and restore capabilities: Enables backup and restoration of configurations, a functionality not standardized in SNMP.
- Distinguishes configuration from state data: Allows network administrators to separately identify and compare configuration data and operating state.
YANG as the data modeling standard for NETCONF
YANG emerged in 2010 as a specialized data modeling language, defining data sent over the NETCONF network management protocol. Developed to address the unique challenges of network systems, YANG provides a standardized framework for defining how network devices are configured and managed. It enables the detailed specification of network devices' configuration, operational data, and policies in a structured, modular, and extensible manner, facilitating automation and reducing the likelihood of configuration errors.
A YANG model is essentially a schema. In the context of data modeling, a schema can be thought of as a blueprint or a map that outlines the structure and type of data. It’s like a template that dictates what data is allowed and how it should be organized. For example, in a YANG model, a schema might specify that a router’s configuration data includes fields for its IP address and subnet mask. These fields are defined as strings in the schema, meaning they should contain text data. The schema might also define constraints, such as the IP address field must contain a valid IP address format.
This schema describes the hierarchy and types of data that can be used for configuring and monitoring network devices, including routers, switches, and firewalls. These models are used by network management protocols like NETCONF and RESTCONF to communicate with network devices in a standardized format.
The use of YANG models enables network engineers to abstract the complexities of physical and logical network components into manageable, machine-readable formats. This abstraction is key to enabling scalable, automated, and efficient network management practices across diverse network infrastructures. By using a schema, network engineers can ensure that the data they are working with adheres to a specific structure and format, reducing the risk of errors and inconsistencies.
YANG in the ecosystem
The following diagram illustrates YANG in the ecosystem of protocols and technologies allowing data modeling network management:
YANG model providers
YANG models come from several sources, each contributing differently to the ecosystem. Here's an overview of the main types of YANG model providers:
- Vendors
Network device vendors produce YANG models specific to their equipment. While vendor-specific models offer granular control over proprietary features, their utility is generally confined to the vendor’s own devices, which may limit interoperability across a diverse network infrastructure. YANG models provided directly by vendors for their own equipment are commonly referred to as 'native' models.
- IETF
Adopted YANG as a standard data modeling language for NETCONF protocol in 2010. Defines standard data types used in YANG and provides modules for common entities like interfaces, routing, etc.
- Other agencies
Standardization bodies, including IEEE, ETSI, MEF, and BBF focus on specific network technologies or services, producing models that address particular needs or scenarios within their domains of expertise, building upon architecture and hierarchy provided by IETF-defined nodes.
- OpenConfig
OpenConfig is an initiative by network operators aiming to establish vendor-neutral, model-driven management for network devices. It operates as a consortium, reflecting the operational needs of its members to develop practical, operator-friendly YANG models. OpenConfig’s objective is to create a set of open, standard models that enable consistent management practices across devices from various vendors, thus facilitating automation.
The implementation of any YANG model is contingent upon the network device's support for that model. This means that for a network management task to be automated or simplified through a YANG model, the target device must inherently support the specific model being used. Compatibility between devices and YANG models is therefore a critical factor in network management, emphasizing the need for careful selection of models that align with the network devices’ supported features and standards.
To discover a device's YANG capabilities, IETF introduced the ‘ietf-netconf-monitoring’ data model. Upon querying the device, it retrieves the NETCONF capabilities supported, list of datastores and schemas, and other key information.
Anatomy of YANG models
Before delving into specific examples and the practical applications of YANG models, it is essential to first understand their structural components.
Below is a diagram that illustrates a structure overview of the YANG model:
Based on the diagram above, the key components of YANG include:
-
Modules: The module statement defines the most fundamental block of a YANG file. It encapsulates the definitions and statements that belong together as a logical unit. Example:
module junos-es-conf-routing-options { namespace "http://yang.juniper.net/junos-es/conf/routing-options"; prefix jc-routing-options; }As seen in the example above, ‘junos-es-conf-routing-options’ has the following declarations:
- namespace: URI that uniquely identifies the YANG model. This namespace ensures that the names defined in this module do not conflict with names in other YANG modules. It acts like a "namespace" in programming languages, segregating and specifying the scope where identifiers such as variables, functions, and classes are valid.
- prefix: serves as a shorthand representation of the namespace. It is used to reference elements defined in this module in a more succinct manner.
-
Imports: Modules can use definitions from other modules through the import statement; as seen in the following example:
import junos-es-conf-root { prefix jc; }This helps in reusing common data structures and types across different models without redefining them. Each import is identified by a prefix used to reference imported items. In this case the 'junos-es-conf-root’ module will be referenced by ‘jc’.
-
Augments: The augment statement is used to add schema nodes to the schema tree of another module's data hierarchy. It allows extending the functionality of a module by adding additional configuration or state data nodes:
augment "/jc:configuration" { uses routing-options-group; }In this example, ‘routing-options-group’ is added to the data tree at the path specified, enhancing the configuration container within the jc namespace.
-
Containers: A container, identified by a name, functions similarly to a class in object-oriented programming, by grouping structures, data and validation stemming from the used data types.
container routing-options { description "Protocol-independent routing option configuration"; }Here, the ‘routing-options’ container is being defined. As per the description, it’s intended to group protocol-independent routing settings.
-
Lists and leaf-lists: Lists are found in YANG model tabular data, where each entry, identified by a unique key, represents a complex element with potentially multiple sub-elements. Leaf-lists, on the other hand, are simpler, storing a list of primitive values without further subdivision.
list route { key name; leaf name { type jt:ipprefix; } leaf another-attribute {...} }In this example, a list named ‘route’ uses ‘name’ as a unique key and includes multiple attributes per entry, mimicking a table row with multiple columns.
-
Leaves: A leaf is the most basic unit in a YANG model, representing a singular data point within the configuration, similar to a variable in programming. Leafs are elemental nodes holding single pieces of data, and they do not contain any child nodes.
leaf name { type jt:ipprefix; }Here, the leaf named ‘name’ holds an IP prefix demonstrating how specific, discrete configuration values are defined in YANG.
-
Data types and constraints: Each leaf in a YANG model has a type that defines the kind of data the leaf can hold. YANG provides built-in types like string, int32, boolean, and many others. Complex types can also be defined or extended using typedef. More details regarding data types follow in the next section
YANG data types
Data types in programming and data modeling define the kind of data a variable can hold and dictate the operations that can be performed on that data. In the context of YANG, data types define how data is structured and validated within the network management system.
Built-in data types
The YANG data modeling language, as specified in RFC 6020, includes a set of built-in data types that provide a foundation. Here are some examples of these built-in types:
- binary: used for representing any binary data,
- bits: defines a set of bits or flags,
- boolean: holds one of two possible values, “true” or “false”,
- empty: indicates a leaf that does not have any value,
- int8/16/32/64: signed integer of specific size,
- uint8/16/32/64: unsigned integer of specific size,
- string: a sequence of characters for human-readable text,
- union: a type that can hold one of several user-specified types.
For a full overview of built-in data types, refer to RFC 6020 
.
Derived types
Apart from the standard built-in types, YANG allows the creation of custom or derived data types. These derived types are used to represent more complex data structures or to restrict built-in types with additional rules. RFC 6021 expands on YANG's capabilities by introducing a collection of core derived data types that aid in the creation of YANG models. Some of these common types include:
- counter32 and counter64: used for non-negative integers that increase until they reach a maximum value and then roll over to zero,
- ip-address, ipv4-address, and ipv6-address: used to define IP addresses,
- mac-address: defines MAC addresses,
- uri: used to define uniform resource identifiers.
For a full overview of core derived data types refer to RFC 6021 .
As illustrated by the derived type inet:ipv4-address, additional rules can further refine the behavior of types in YANG. This derived type is based on the built-in string type, but it incorporates a specific validation pattern to ensure that the value conforms to the IPv4 address format. The type definition for ipv4-address is as follows:
typedef ipv4-address {
type string {
pattern
'(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+ '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
+ '(%[\p{N}\p{L}]+)?';
}
description
[...] output omitted [...];
}
Applicability of YANG
YANG is applicable across a broad range of network management scenarios, including but not limited to:
- Configuration management: Automating the provisioning and synchronization of network configurations, reducing manual errors, and enhancing operational efficiency.
- Network state monitoring: Leveraging YANG models for real-time monitoring and validation of network states, facilitating proactive management and troubleshooting.
- Service orchestration: Supporting complex service definitions and orchestration in NFV and SDN architectures, enabling dynamic, on-demand network services.
Together with NETCONF/RESTCONF, YANG forms a foundational framework for automating network operations. Given the applications mentioned above, YANG, alongside NETCONF/RESTCONF, frequently lies at the core of modern network management systems (NMS). To read more about different management protocols see our previous article.
YANG in practice
In this section, we will explore the practical application of YANG using a Junos OS-based appliance. Below is an overview of the device specifications:
lab@vSRX> show version brief
Hostname: vSRX
Model: vSRX
Junos: 20.4R2.7
[...] output omitted [...]
The topology in this example is as follows:
Enabling NETCONF connections
The first step is to enable NETCONF connections using the following configuration statement:
lab@vSRX# set system services netconf yang-compliant ssh
This will allow for NETCONF connections over SSH. The ‘YANG-compliant’ option directs the NETCONF server to return YANG-compatible configuration data that is consistent with the device's YANG schema and RFC 6020. For more information refer to the CLI reference guide .
After committing this configuration it is now possible to establish NETCONF connections on ports 22 and 830 as show below:
ssh lab@192.168.55.99 -p 830 -s netconf
NETCONF session initialization
Upon establishing a NETCONF session, the server communicates its capabilities, as in the example below:
<!-- No zombies were killed during the creation of this user interface -->
<!-- user lab, class j-super-user -->
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring</capability>
<capability>http://xml.juniper.net/netconf/junos/1.0</capability>
[...] output omitted [...]
</capabilities>
<session-id>21499</session-id>
</hello>
]]>]]>
The ‘]]>]]>’ sequence at the end of the message is a marker used in NETCONF to delimit the end of a message, ensuring that message parsing is correctly handled by both the client and the server.
Accessing YANG data models
Junos OS is equipped with device-specific YANG data models for both configuration and operational commands. To demonstrate YANG data model usage we will choose a model for sample operational command. All device specific-models can be accessed either by visiting Juniper's YANG model repository or directly from the device itself. To retrieve the models from the device, the following RPC call using NETCONF can be executed:
<rpc>
<get-yang-schema>
<format>yang</format>
<identifier>all</identifier>
<output-directory>/var/home/lab</output-directory>
</get-yang-schema>
</rpc>
]]>]]>
or by executing the following command in Junos:
show system schema format yang module all output-directory /var/home/lab
As a result all device-specific YANG data models are rendered into the provided directory.
Example operational module: junos-es-rpc-route
Among the available modules, ‘junos-es-rpc-route’ is particularly useful. It provides a YANG model for various routing commands, including the equivalent of the ‘show route’ CLI’s command. Let's begin by examining the standard ‘show route’ command output:
lab@vSRX> show route
inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 04:41:06
> to 192.168.55.2 via ge-0/0/0.0
192.168.55.0/24 *[Direct/0] 04:41:06
> via ge-0/0/0.0
192.168.55.99/32 *[Local/0] 04:41:06
Local via ge-0/0/0.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
ff02::2/128 *[INET6/0] 04:41:32
MultiRecv
This output shows two active routing tables: ‘inet.0’ and ‘inet.6’. In the case of ‘inet.0’ there is one interface route, one directly attached route and one configured static route.
The ‘junos-es-rpc-route‘ module includes an RPC named ‘get-route-information‘ that is an equivalent of the show route command. Here's a partial view of the YANG model for this RPC:
module junos-es-rpc-route {
namespace "http://yang.juniper.net/junos-es/rpc/route";
prefix route;
import junos-common-types {
prefix jt;
revision-date 2019-01-01;
}
[...] output omitted [...]
rpc get-route-information {
description "Show routing table information";
input {
leaf destination {
description "IP address and optional prefix length of destination";
type jt:ipprefix-optional;
}
leaf level {
type enumeration {
enum "terse" {
description "Display terse output";
}
enum "brief" {
description "Display brief output";
}
enum "detail" {
description "Display detailed output";
}
enum "extensive" {
description "Display extensive output";
}
}
}
leaf match {
type enumeration {
enum "best" {
description "Show longest matching route";
}
enum "exact" {
description "Show routes that match exactly";
}
enum "range" {
description "Show all entries in prefix range";
}
}
}
leaf table {
description "Name of routing table";
type string;
}
[...] output omitted [...]
}
[...] output omitted [...]
}
}
Executing the RPC call
To retrieve information about the device’s routing tables, which corresponds to the show route command, the following structured RPC call is made through the NETCONF connection established earlier:
<rpc>
<get-route-information/>
</rpc>
]]>]]>
The NETCONF server responds with structured data serialized to XML, as in the output below:
<route-information xmlns="http://xml.juniper.net/junos/20.4R0/junos-routing">
<route-table>
<table-name>inet.0</table-name>
<destination-count>3</destination-count>
<total-route-count>3</total-route-count>
<active-route-count>3</active-route-count>
<holddown-route-count>0</holddown-route-count>
<hidden-route-count>0</hidden-route-count>
<rt junos:style="brief">
<rt-destination>0.0.0.0/0</rt-destination>
<rt-entry>
<active-tag>*</active-tag>
<current-active />
<last-active />
<protocol-name>Static</protocol-name>
<preference>5</preference>
<age junos:seconds="10595">02:56:35</age>
<nh>
<selected-next-hop />
<to>192.168.55.2</to>
<via>ge-0/0/0.0</via>
</nh>
</rt-entry>
</rt>
<rt junos:style="brief">
<rt-destination>192.168.55.0/24</rt-destination>
<rt-entry>
<active-tag>*</active-tag>
<current-active />
<last-active />
<protocol-name>Direct</protocol-name>
<preference>0</preference>
<age junos:seconds="10595">02:56:35</age>
<nh>
<selected-next-hop />
<via>ge-0/0/0.0</via>
</nh>
</rt-entry>
</rt>
<rt junos:style="brief">
<rt-destination>192.168.55.99/32</rt-destination>
<rt-entry>
<active-tag>*</active-tag>
<current-active />
<last-active />
<protocol-name>Local</protocol-name>
<preference>0</preference>
The above output represents the same data as the human-readable output of the ‘show route’ command.
Parametrization of RPC calls
Through the detailed structure of the ‘junos-es-rpc-route’ YANG module, we can observe that the input parameters can be dynamically defined. These parameters are represented by XML tags in the RPC calls, allowing for customizable requests. Some of the input parameters include:
- destination: specifies the IP address and optional prefix length,
- level: determines the verbosity of the output (terse, brief, detailed, extensive),
- match: sets the criteria for route selection (best, exact, range),
- table: indicates the specific routing table to query.
The following is a representation of these parameters in the ‘junos-es-rpc-route’ YANG module:
[...] output omitted [...]
input {
leaf destination {
description "IP address and optional prefix length of destination";
type jt:ipprefix-optional;
}
leaf level {
type enumeration {
enum "terse" {
description "Display terse output";
}
enum "brief" {
description "Display brief output";
}
enum "detail" {
description "Display detailed output";
}
enum "extensive" {
description "Display extensive output";
}
}
}
leaf match {
type enumeration {
enum "best" {
description "Show longest matching route";
}
enum "exact" {
description "Show routes that match exactly";
}
enum "range" {
description "Show all entries in prefix range";
}
}
}
leaf table {
description "Name of routing table";
type string;
}
[...] output omitted [...]
Example of a parametrized RPC call
To demonstrate the parametrization, consider this RPC call structured to retrieve specific routing information from the ‘inet.0’ table, showing only the route for 0.0.0.0/0 in a terse format:
<rpc>
<get-route-information>
<level>terse</level>
<table>inet.0</table>
<destination>0.0.0.0/0</destination>
<match>exact</match>
</get-route-information>
</rpc>
]]>]]>
The response from the NETCONF server is an XML structured output that adheres to the specified parameters of the RPC call:
<route-table>
<table-name>inet.0</table-name>
<destination-count>3</destination-count>
<total-route-count>3</total-route-count>
<active-route-count>3</active-route-count>
<holddown-route-count>0</holddown-route-count>
<hidden-route-count>0</hidden-route-count>
<rt junos:style="terse">
<rt-destination>0.0.0.0/0</rt-destination>
<rt-entry>
<active-tag>*</active-tag>
<validation-state>?</validation-state>
<current-active />
<last-active />
<protocol-name>Static</protocol-name>
<preference>5</preference>
<nh>
<selected-next-hop />
<to>192.168.55.2</to>
</nh>
</rt-entry>
</rt>
</route-table>
</route-information>
This output effectively displays the route information for 0.0.0.0/0, demonstrating the effectiveness of parametrization.
Example configuration using module: junos-es-conf-routing-options
The ‘junos-es-conf-routing-options’ module provides a framework for routing options configuration, including static routes. Below is a partial view of how this model is structured:
module junos-es-conf-routing-options {
namespace "http://yang.juniper.net/junos-es/conf/routing-options";
prefix jc-routing-options;
[...] output omitted [...]
import junos-es-conf-root {
prefix jc;
revision-date 2019-01-01;
}
augment /jc:configuration {
uses routing-options-group;
}
augment /jc:configuration/jc:groups {
uses routing-options-group;
}
grouping routing-options-group {
container routing-options {
description "Protocol-independent routing option configuration";
uses juniper-routing-options;
}
}
grouping juniper-routing-options {
container static {
description "Static routes";
list route {
key name;
ordered-by user;
description "Static route";
leaf name {
type jt:ipprefix;
}
choice next_hop {
case case_1 {
leaf-list next-hop {
ordered-by user;
description "Next hop to destination";
type union {
type jt:ipaddr-or-interface;
type string {
pattern "<.*>|$.*";
}
}
}
}
}
[...] output omitted [...]
}
}
}
}
Configuring a static route
By analyzing ‘junos-es-conf-routing-options’, we can identify that grouping ‘routing-options-group’ defines the ‘routing-options’ container, which uses the ‘juniper-routing-options’ grouping, as seen in the snippet below:
grouping routing-options-group {
container routing-options {
uses juniper-routing-options;
}
}
Furthermore, the ‘juniper-routing-options’ grouping defines the ‘static’ container, which requires ‘name’ and ‘next-hop’ leaves:
grouping juniper-routing-options {
container static {
list route {
key name;
leaf name {...}
choice next_hop {...}
}
}
}
The ‘routing-options-group’ presented above augments ‘configuration’:
augment /jc:configuration {
uses routing-options-group;
}
Based on this structure, the following RPC call can be crafted:
<rpc>
<edit-config>
<target>
<candidate/>
</target>
<config>
<configuration>
<routing-options>
<static>
<route>
<name>192.168.0.0/24</name>
<next-hop>192.168.55.1</next-hop>
</route>
</static>
</routing-options>
</configuration>
</config>
</edit-config>
</rpc>
]]>]]>
The NETCONF server's positive acknowledgment indicates that the configuration has been correctly parsed and is ready to be committed:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/20.4R0/junos">
<ok/>
</rpc-reply>
]]>]]>
To commit the newly added static route into the active configuration, the following RPC command is used:
<rpc>
<commit/>
</rpc>
]]>]]>
The device's acknowledgment of this command confirms that the changes have been successfully committed to the device’s configuration.
These examples illustrate how to interact with a NETCONF-enabled device using operational and configuration data models. By utilizing NETCONF and the corresponding YANG models, these methods enable streamlined network monitoring and configuration.
Glossary
BBF Broadband Forum
CLI command-line interface
ETSI European Telecommunications Standards Institute
gNMI gRPC Network Management Interface
gRPC gRPC Remote Procedure Call
IETF Internet Engineering Task Force
lP Internet protocol
MAC media access control
MEF Metro Ethernet Forum
NETCONF network configuration protocol
NFV network function virtualization
NMS network management system
OS operating system
RESTCONF Representational State Transfer Configuration Protocol
RPC remote procedure call
SDN software-defined network
SMI Structure of Management Information
SNMP Simple Network Management Protocol
SSH Secure Shell
URI uniform resource identifiers
XML Extensible Markup Language
XPATH XML Path Language
YANG Yet Another Next Generation
