Understanding the Management of Nonnative YANG Modules on Devices Running Junos OS

YANG is a standards-based, extensible data modeling language that is used to model the configuration and operational state data, remote procedure calls (RPCs), and server event notifications of network devices. Devices running Junos OS enable you to load standard or custom YANG models onto the device to add data models that are not natively supported by Junos OS but can be supported by translation. Doing this is beneficial when you want to create device-agnostic and vendor-neutral operational and configuration models that enable the same RPC or configuration to be used on different devices from one or more vendors.

When you add YANG data models that are not natively supported by devices running Junos OS, you must also supply a script that handles the translation logic between the YANG data model and Junos OS for that device. There are two types of scripts:

• Translation scripts are Stylesheet Language Alternative SyntaX (SLAX) or Python scripts that map the custom configuration syntax defined by the YANG model to Junos OS syntax and then load the translated data into the configuration as a transient change during the commit operation. When you load and commit configuration data in the nonnative hierarchies on those devices, Junos OS invokes the script to perform the translation and emit the transient change.

• Action scripts are SLAX or Python scripts that act as handlers for your custom YANG RPCs. The YANG RPC definition uses a Junos OS YANG extension to reference the appropriate action script, which is invoked when you execute the RPC.

To use custom YANG data models on devices running Junos OS, you must add the YANG modules and associated scripts to the device by issuing the request system yang add command. Junos OS validates the syntax of the modules and scripts, rebuilds its schema to include the new data models, and then validates the active configuration against this schema. Although the device validates the modules and scripts as you add them, we recommend that you validate the syntax prior to merging them with the Junos OS schema by first executing the request system yang validate command.

When you add YANG modules and scripts to devices running Junos OS, you must associate them with a package. Packages have a unique identifier and represent a collection of related modules, translation scripts, and action scripts. You reference the package identifier if you later update modules and scripts in that package, enable or disable translation scripts associated with the package, or delete that group of modules and scripts from the device.

When you add, update, or remove YANG modules and scripts on the device by issuing the appropriate operational commands, you do not need to reboot the device in order for the changes to take effect. Newly added RPCs and configuration hierarchies are immediately available for use, and installed translation scripts are enabled by default. You can disable translation scripts in a package at any time without removing the package and associated files from the device, which can be useful when troubleshooting translation issues. When you disable translation for a package, you can configure and commit the statements and hierarchies added by the YANG modules in that package, but the device does not translate and commit the corresponding Junos OS configuration as a transient configuration change during the commit operation.

Before installing software on a device that has one or more custom YANG data models added to it, you must remove all configuration data corresponding to the custom YANG data models from the active configuration. After the software installation is complete, add the YANG packages and corresponding configuration data back to the device, if appropriate. For more information see Managing YANG Packages and Configurations During a Software Upgrade or Downgrade.