YANG is a modeling language in the Network Configuration Protocol (NETCONF). YANG defines a hierarchical data structure, which is used for NETCONF-based operations, including configuration, state data, Remote Procedure Calls (RPCs), and notifications. This allows a complete description of all data exchanged between a NETCONF client and server.
Modules and submodules: YANG structures data models into modules and submodules. A module can import data from other modules and reference data from submodules. The hierarchy can be augmented, allowing one module to add data nodes to the hierarchy defined in another module. This augmentation is conditional, with new nodes presented only if certain conditions are met.
"import" and "include" statements for modules and submodules: The "include" statement allows a module or submodule to reference materials in submodules, and the "import" statement allows references to materials defined in other modules.
The namespace of a module must be globally unique.
The "revision" statement records the version change history of a module. Any updated revision information must be associated with the corresponding file name.
Module description and introduction
The "organization" and "contact" statements provide organization and contact information about the module so that the source of the module can be determined.
The "description" statement describes basic module information.
Example of a YANG model file
Contents of "acme-system.yang"
module acme-system {
namespace "http://acme.example.com/system";
prefix "acme";
organization "ACME Inc.";
contact "joe@acme.example.com";
description
"The module for entities implementing the ACME system.";
revision 2007-06-09 {
description "Initial revision.";
}
container system {
leaf host-name {
type string;
description "Hostname for this system";
}
leaf-list domain-search {
type string;
description "List of domain names to search";
}
container login {
leaf message {
type string;
description
"Message given at start of login session";
}
list user {
key "name";
leaf name {
type string;
}
}
}
}
}
You can define operations in the YANG model through RPCs or the "action" statement. The definitions include operation names, input parameters, and output parameters.
Defining an operation through an RPC
YANG provides the RPC keyword, and an operation at the top layer of the model can be defined.
The following example shows an operation defined using an RPC. The operation name is activate-software-image. The input parameter is image-name, which is specified as a character string, and the output parameter is status, which is also specified as a character string.
rpc activate-software-image {
input {
leaf image-name {
type string;
}
}
output {
leaf status {
type string;
}
}
}
The corresponding NETCONF XML example is as follows.
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <activate-software-image xmlns="http://acme.example.com/system"> <image-name>acmefw-2.3</image-name> </activate-software-image> </rpc> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <status xmlns="http://acme.example.com/system"> The image acmefw-2.3 is being installed. </status> </rpc-reply>
Defining an operation through the "action" statement
Action is syntax of YANG. It can be associated with the container and list nodes to define operations such as <reset>, <reboot>, and <copy> for leaf nodes. Action includes the input and output statements.
One leaf node can have multiple operations defined, but only one operation is delivered each time.
In the following example, a list node named server is associated with the "action" statement, which defines a reset operation for a leaf node named reset-at.
module example-server-farm {
yang-version 1.1;
namespace "urn:example:server-farm";
prefix "sfarm";
import ietf-yang-types {
prefix "yang";
}
list server {
key name;
leaf name {
type string;
}
action reset {
input {
leaf reset-at {
type yang:date-and-time;
mandatory true;
}
}
output {
leaf reset-finished-at {
type yang:date-and-time;
mandatory true;
}
}
}
}
}
The corresponding NETCONF XML description is as follows: The reset operation is performed for the server named apache-1 at the user-specified time "2014-07-29T13:42:00Z", and a reply packet indicating the execution end time is returned.
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action xmlns="urn:ietf:params:xml:ns:yang:1">
<server xmlns="urn:example:server-farm">
<name>apache-1</name>
<reset>
<reset-at>2014-07-29T13:42:00Z</reset-at>
</reset>
</server>
</action>
</rpc>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <reset-finished-at xmlns="urn:example:server-farm"> 2014-07-29T13:42:12Z </reset-finished-at> </rpc-reply>
NETCONF notification is a NETCONF-based mechanism for alarm and event subscription and reporting, providing a data-model-based asynchronous reporting service. YANG allows the definition of notifications suitable for NETCONF. YANG data definition statements are used to model the notification content.
NETCONF is different from the single-transmission and single-receiving mechanisms of RPC packets, which a client uses to query data. NETCONF notifications allow a server to proactively send notification packets to a client in case of an alarm or an event. NETCONF notification applies to scenarios where real-time detection of devices is required, such as, alarms and events reported to an NMS through NETCONF.
The following example shows a defined notification. The name is link-failure. If any of the if-name, if-admin-status, and if-oper-status parameter values changes, the change is reported to a client.
notification link-failure {
description "A link failure has been detected";
leaf if-name {
type leafref {
path "/interface/name";
}
}
leaf if-admin-status {
type admin-status;
}
leaf if-oper-status {
type oper-status;
}
}
The corresponding NETCONF XML example is as follows.
<notification xmlns="urn:ietf:params:netconf:capability:notification:1.0"> <eventTime>2007-09-01T10:00:00Z</eventTime> <link-failure xmlns="http://acme.example.com/system"> <if-name>so-1/2/3.0</if-name> <if-admin-status>up</if-admin-status> <if-oper-status>down</if-oper-status> </link-failure> </notification>