My Personal Notes on the Yang Data Model

Yet Another Next Generation, YANG YANG is the data modelling language. It is a modern replacement of mibs used in snmp. Could think of it as SNMPv4.

Do not confuse with YANG Data Models. (see YANG Data Models below)

Here is some YANG

  module ietf-interfaces {
  import ietf-yang-types {
    prefix yang;
  }
  container interfaces {
    list interface {
      key "name";
      leaf name {
        type string;
      }
      leaf enabled {
        type boolean;
        default "true";
    }
}

You will notice that the YANG model has these statements:

• model
• augment
• container
• list
• leaf

That follows this YANG data model

- Model
  - container
    - list
      - leaf
      - leaf
      - leaf
    - list
      - leaf
      - leaf
    - leaf
  - container
    - list
      - leaf
      - leaf

From Wikipedia, "YANG (Yet Another Next Generation)[3] is a data modeling language for the definition of data sent over network management protocols such as the NETCONF and RESTCONF. The YANG data modeling language is maintained by the NETMOD [6] 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.

YANG models were defined in 2010. RFC 6020 NETCONF defined in 2006, RFC 4741 RESTCONF defined in 2017, RFC 8040 gRPC defined in 2015, by Google.

Transport Protocol could be NETCONF, RESTCONF, or gRPC, but all of these carry the same data, represented in this case. YANG Data Model. i.e. Payload is in the YANG format.

YANG is expressed in XML, so an instance of something modelled in YANG, is an XML document. As such, there is a mapping from a YANG model into a XML document.

YANG attributes are defined in leafs, which maps to an XML document element with the same name. Note: in the XML document, the lists remain un-named, and un-ordered, and do nost contain any <list></list> elements. If you need such elements, you would use a container in the YANG model. i.e. Lists are used for multiple instances in an XML doc, but not attributes or leaf objects.

They all basically mean the same thing, depending on the Context.

yang itself is a language. there are about 5 "standard" data models that use yang:

1. ietf,
2. itu,
3. google's openconfig, &
4. vendor specific.

A YANG model could describe a service such as an MPLS VPN service.

From Cisco training:* The next listing shows a notification, with the YANG definition followed by an example in XML encoding.

YANG Definition:

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 same definition, now in the XML encoding:

<notification xmlns="…">
  <eventTime>2016-09-01T10:00:00Z</eventTime>
  <link-failure xmlns="…">
    <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>

NETCONF notifications are defined in RFC 5277. This optional capability is an addition to the base NETCONF definition. The notification mechanism is conceptually one of subscribing to a stream of notifications with a filter, and with start and stop times for notification replay.

The notification statement takes one argument, which is an identifier, followed by a block of substatements that holds detailed notification information.

The example has the YANG definition for a link failure notification, including the interface name and the administration and operational statuses. It is possible for an interface to be in the administration status of "up", meaning it is configured to be available. However, in the example, it is operationally down—perhaps because someone disconnected the cable from the port.