Understanding Junos YANG Modules

Junos YANG Modules Overview

Juniper Networks provides YANG modules that define the configuration hierarchies, operational commands and state data, as well as YANG extensions and types, for devices running Junos OS and devices running Junos OS Evolved. Starting in Junos OS Release 17.2, the YANG modules are specific to a device family. Table 1 outlines the identifiers for the different device families and indicates which platforms are included in each family. Starting in Junos OS Evolved Release 23.4R2, all Junos OS Evolved platforms use the junos device family identifier.

Starting in Junos OS Release 17.4R1, the configuration YANG module is split into a root module that is augmented by multiple smaller modules. Additionally, the native Junos YANG modules use a new naming convention for the module's name, filename, and namespace. The module name and filename include the device family and the area of the configuration or command hierarchy to which the schema in the module belongs. The module filename also includes a revision date. Table 2 summarizes the YANG modules that are native to Junos devices and identifies the release in which the different module names are used.

To support YANG modules for different device families in different releases, the downloaded modules are organized by device family, and each module’s name, filename, and namespace reflects the device family to which the schema in the module belongs.

For information about obtaining the modules, see Download and Generate Junos YANG modules.

For information about the module namespaces, see Understanding Junos YANG Module Namespaces and Prefixes.

Download and Generate Junos YANG modules

You can retrieve the Junos OS and Junos OS Evolved YANG modules by:

• Downloading the modules from the Juniper Networks website at https://www.juniper.net/support/downloads

• Downloading the modules from the Juniper/yang GitHub repository

• Generating the modules on a Juniper Networks device

In Junos OS Release 17.1 and earlier, the YANG modules for the Junos OS configuration and command hierarchies that are posted on the Juniper Networks website and in GitHub define the schema for all devices running that Junos OS release. By contrast, the YANG modules generated on the local device define the schema specific to that device. The device-specific schema includes nodes both from native modules and from any standard or custom modules that were added to the device.

Starting in Junos OS Release 17.2, Junos YANG modules are specific to a device family and each module’s namespace reflects the device family to which the schema in the module belongs. As a result, the download package and GitHub repository include a separate directory for each device family’s modules and a common directory for the modules that are common to all device families. Each family-specific directory uses its device family identifier as the directory name and contains the configuration and operational command modules that are supported on the platforms in that family. The device family identifiers are defined in Table 1. The YANG modules generated on a local device running Junos OS Release 17.2 still define the schema specific to that device.

Starting in Junos OS Release 17.4R1, the YANG modules generated on a local device, by default, contain family-specific schemas, which are identical across all devices in the given device family. To generate device-specific modules, configure the device-specific configuration statement at the [edit system services netconf yang-modules] hierarchy level.

Table 3 summarizes the scope of the schema in the downloaded and generated YANG modules for different Junos OS releases.

Starting in Junos OS Evolved Release 23.4R1, we publish the Junos OS Evolved YANG modules on the Juniper Networks download site and on GitHub. In earlier releases, you must generate the modules on the device.

Additionally, starting in Junos OS Release 23.4R1 and Junos OS Evolved Release 23.4R1, we provide all YANG data models for a given OS and release in a single download package and GitHub repository folder. The package and repository folder include:

• Native configuration, state, and RPC data models

• OpenConfig configuration and state models supported by that OS

• IETF models supported by that OS

For more information about how to download or generate the Junos OS YANG modules, see Use Juniper Networks YANG Modules.

Understanding Junos YANG Module Namespaces and Prefixes

In Junos OS Release 17.1 and earlier, Junos YANG modules use a unique identifier to differentiate the namespace for each module.

Starting in Junos OS Release 17.2R1, the Junos YANG modules are specific to a device family. To support distinct YANG modules for different device families in a given release, the YANG modules use a namespace that includes the module name, the device family, and the Junos OS release string, in addition to the identifier. For example:

Starting in Junos OS Release 17.4R1, the namespace is simplified to include the device family, the module type, and an identifier that is unique to each module and that differentiates the namespace of the module from that of other modules.

The following definitions apply to all versions of the namespace in which that variable appears:

Table 4 outlines each module’s namespace URI and prefix (as defined by the module’s prefix statement) in the different releases. Starting in Junos OS Release 17.2, the prefix for each operational command module reflects the command hierarchy area of the RPCs included in that module. Similarly, starting in Junos OS Release 17.4R1, the prefix for each configuration YANG module reflects the configuration statement hierarchy that is included in that module. The Junos YANG extension and type modules use the junos device family identifier in the namespace, but the modules are common to all device families.

Starting with Junos OS Release 17.2, when you configure the rfc-compliant statement at the [edit system services netconf] hierarchy level and request configuration data in a NETCONF session, the server sets the default namespace for the <configuration> element to the same namespace as in the corresponding YANG model. For example: