YANG

YANG (Yet Another Next Generation) is a data modeling language for the definition of data sent over the NETCONF network configuration protocol. The YANG data modeling language was developed by the NETMOD working group in the Internet Engineering Task Force (IETF) and was published as RFC 6020 in October 2010. The data modeling language can be used to model both configuration data as well as state data of network elements. Furthermore, YANG can be used to define the format of event notifications emitted by network elements and it allows data modelers to define the signature of remote procedure calls that can be invoked on network elements via the NETCONF protocol. The language, being protocol independent, can then be converted into any encoding format, e.g. XML or JSON, that the network configuration protocol supports.

YANG is a modular language representing data structures in an XML tree format. The data modeling language comes with a number of built-in data types. Additional application specific data types can be derived from the built-in data types. More complex reusable data structures can be represented as groupings. YANG data models can use XPATH expressions to define constraints on the elements of a YANG data model.

History

Many network management protocols have associated data modeling languages. The first widely deployed Internet standard for network management was the Simple Network Management Protocol (SNMP). The data modeling language associated with SNMP was called the Structure of Management Information (SMI). The SMI language itself was based on the 1988 version of the Abstract Syntax Notation One (ASN.1). The current version of the SMI language, SMIv2 defined in RFC 2578, RFC 2579, RFC 2580, has developed into an extended subset of ASN.1.

In the late 1990s, a project was started to create a replacement for SMIv2, which was called SMIng. One motivation was to decouple SMIng from the management protocol SNMP and to give SMIng a syntactic structure that is both easy to parse for computer programs and easy to learn for people familiar with programming languages that use a C-like notation. While the SMIng project did not succeed in the IETF, the SMIng specifications were published as experimental documents in May 2004 (RFC 3780, RFC 3781).

Soon after the development of the NETCONF protocol in the IETF, it became clear that a data modeling language was needed to define data models manipulated by the NETCONF protocol. A design team created a proposal that became the basis of the YANG language. The syntactic structure and the base type system was essentially borrowed from SMIng. However, based on the lessons learned from the SMIng project, no attempts were made to make YANG protocol neutral. Instead, YANG ties into concepts of the NETCONF protocol, such as the assumption that data model instances can be serialized into XML. Standardization of YANG started with the formation of the NETMOD working group in April 2008. The YANG 1.0 specification was published as RFC 6020 in October 2010. Recently, the NETMOD working group has been working on YANG 1.1, which has been published in August 2016 in RFC 7950.

Example

The following YANG module example-sports shows a data model for team sports. The module declares a namespace and a prefix and imports the type library module ietf-yang-types before defining the type season. It then defines a container sports that includes a list of persons and a list of teams. A team has a list of players that reference persons via the leafref type and its path restriction.

module example-sports {

  namespace "http://example.com/example-sports";
  prefix sports;

  import ietf-yang-types { prefix yang; }

  typedef season {
    type string;
    description
      "The name of a sports season, including the type and the year, e.g,
       'Champions League 2014/2015'.";
  }

  container sports {
    config true;

    list person {
      key name;
      leaf name { type string; }
      leaf birthday { type yang:date-and-time; mandatory true; }
    }

    list team {
      key name;
      leaf name { type string; }
      list player {
        key "name season";
        unique number;
        leaf name { type leafref { path "/sports/person/name"; }  }
        leaf season { type season; }
        leaf number { type uint16; mandatory true; }
        leaf scores { type uint16; default 0; }
      }
    }
  }
}

XML Encoding

The code block below shows the XML representation of an instantiation of the example-sports data model.

<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <sports xmlns="http://example.com/example-sports">
    <person>
      <name>Lionel Andrés Messi</name>
      <birthday>1987-06-24T00:00:00-00:00</birthday>
    </person>
    <person>
      <name>Cristiano Ronaldo</name>
      <birthday>1985-02-05T00:00:00-00:00</birthday>
    </person>
    <team>
      <name>FC Barcelona</name>
      <player>
        <name>Lionel Andrés Messi</name>
        <season>Champions League 2014/2015</season>
        <number>10</number>
        <scores>43</scores>
      </player>
    </team>
    <team>
      <name>Real Madrid</name>
      <player>
        <name>Cristiano Ronaldo</name>
        <season>Champions League 2014/2015</season>
        <number>7</number>
        <scores>48</scores>
      </player>
    </team>
  </sports>

</data>

JSON Encoding

The code block below shows the JSON representation of an instantiation of the example-sports data model.

{
  "example-sports:sports": {
    "person": [
      {
        "name": "Lionel Andrés Messi",
        "birthday": "1987-06-24T00:00:00-00:00"
      },
      {
        "name": "Cristiano Ronaldo",
        "birthday": "1985-02-05T00:00:00-00:00"
      }
    ],
    "team": [
      {
        "name": "FC Barcelona",
        "player": [
          {
            "name": "Lionel Andrés Messi",
            "season": "Champions League 2014/2015",
            "number": 10,
            "scores": 43
          }
        ]
      },
      {
        "name": "Real Madrid",
        "player": [
          {
            "name": "Cristiano Ronaldo",
            "season": "Champions League 2014/2015",
            "number": 7,
            "scores": 48
          }
        ]
      }
    ]
  }
}

Specifications

The following Request for Comments (RFCs) define the YANG language and some basic extensions:

• RFC 6020: YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
• RFC 7950: The YANG 1.1 Data Modeling Language
• RFC 7951: JSON Encoding of Data Modeled with YANG
• RFC 7952: Defining and Using Metadata with YANG

Usage in Standards

The YANG data modeling language has been used by the following Request for Comments (RFCs):

• RFC 6022: YANG Module for NETCONF Monitoring
• RFC 6991: Common YANG Data Types
• RFC 6087: Guidelines for Authors and Reviewers of YANG Data Model Documents
• RFC 6095: Extending YANG with Language Abstractions
• RFC 6110: Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content
• RFC 6241: Network Configuration Protocol (NETCONF)
• RFC 6243: With-defaults Capability for NETCONF
• RFC 6470: Network Configuration Protocol (NETCONF) Base Notifications
• RFC 6536: Network Configuration Protocol (NETCONF) Access Control Model
• RFC 6643: Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules
• RFC 6728: Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols
• RFC 7223: A YANG Data Model for Interface Management
• RFC 7224: IANA Interface Type YANG Module
• RFC 7277: A YANG Data Model for IP Management
• RFC 7317: A YANG Data Model for System Management
• RFC 7407: A YANG Data Model for SNMP Configuration
• RFC 7758: Time Capability in NETCONF
• RFC 7895: YANG Module Library
• RFC 8022: A YANG Data Model for Routing Management
• RFC 8040: RESTCONF Protocol
• RFC 8072: YANG Patch Media Type
• RFC 8177: YANG Data Model for Key Chains
• RFC 8194: A YANG Data Model for LMAP Measurement Agents
• RFC 8199: YANG Module Classification
• RFC 8294: Common YANG Data Types for the Routing Area
• RFC 8299: YANG Data Model for L3VPN Service Delivery

Implementations

Open source implementations:

• goyang is a YANG parser and compiler written in Go to produce Go language objects
• jnc is a pyang-based YANG-to-Java-API compiler
• libyang is a YANG parser and toolkit written C and providing API in C
• pyang is an extensible YANG validator and converter written in Python
• pyangbind is a pyang-based Python binding generator
• yangbuilder is a builder for YANG, implemented in Apache Groovy (generate yang data models with Apache Groovy, maintain similar models with one source code base)
• yang-ide is an Eclipse plugin for editing and visualizing YANG models
• yang tools is an OpenDaylight toolset written in Java
• Yang-Explorer - is a pyang-based Yang Browser and RPC Builder Application
• ydk-gen is a YANG-to-API compiler generating APIs in multiple languages (e.g. Python, C++)
• yuma123 is netconf/YANG toolchain written in C providing: libyuma - API for development of applications supporting runtime compilation of YANG modules, netconfd - modular server, yangcli - interactive command line tool
• Sysrepo is a YANG-based configuration and operational datastore for Unix/Linux applications.
• yang-js is a YANG parser and evaluator written in CoffeeScript/JavaScript for Node.js and the web browser
  • yang-express is a yang-js based Express.js web framework generator
  • yang-swagger is a yang-js based Swagger/OpenAPI specification generator

Closed source implementations:

• confd is a commercial management agent toolkit including a YANG compiler
• MasterYANG is a YANG model designer, visualizer, and editor for Windows
• Visual YANG Designer is a YANG definition file creator/editor/modeler/builder/designer and YANG compiler implemented in Java
• yumapro is a commercial management agent toolkit including a YANG compiler

External links

• Carl Moberg (2015-11-05). YANG by Example (YouTube). Yokohama: IETF EDU Team.
• YANG central - YANG information and tutorials
• YANG Discussion Forum - ConfD User Community Forum for discussing YANG related questions.
• For a list of YANG-based clients and servers see the NETCONF page.