YANG Data Modelling

YANG (RFC 6020, RFC 7950) is a data modeling language used to model configuration and state data for network management protocols like NETCONF and RESTCONF. It was developed by the IETF to provide a standardized, vendor-neutral way to describe the capabilities of network devices. Before YANG, network management relied on proprietary CLI or SNMP MIBs, which were inconsistent across vendors and difficult to automate. YANG solves this by defining a hierarchical tree structure with well-defined data types, constraints, and operations.

A YANG model defines data using nodes: - Leaf: A single, scalar value (e.g., an IP address). - Leaf-list: A list of scalar values (e.g., a list of DNS servers). - Container: A group of related nodes (e.g., interface settings). - List: A sequence of entries, each identified by a key (e.g., multiple interfaces, each with a unique name). - Choice: Allows one option from a set of alternatives. - Anyxml: Can hold any XML data (rarely used in modern models).

Example snippet from the ietf-interfaces YANG model:

container interfaces {
  list interface {
    key "name";
    leaf name {
      type string;
    }
    leaf description {
      type string;
    }
    leaf type {
      type identityref {
        base iana-if-type;
      }
    }
    leaf enabled {
      type boolean;
      default true;
    }
  }
}

YANG models are used by NETCONF (RFC 6241) and RESTCONF (RFC 8040) to encode configuration and operational state data. NETCONF uses XML encoding, while RESTCONF can use XML or JSON. The YANG model defines the schema for these data formats.

#### Step-by-Step Mechanism (NETCONF Example):

1. Device Capability Exchange: During NETCONF session establishment, the device sends a <hello> message listing its supported YANG models (capabilities). 2. Retrieve Schema: A client can retrieve the YANG schema using the get-schema RPC or from a local repository. 3. Configuration Operation: The client sends an <edit-config> operation with XML data conforming to the YANG model. For example, to enable an interface:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <edit-config>
       <target>
         <candidate/>
       </target>
       <config>
         <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
           <interface>
             <name>GigabitEthernet1</name>
             <enabled>true</enabled>
           </interface>
         </interfaces>
       </config>
     </edit-config>
   </rpc>

Use the following CLI commands to verify YANG support and operational data:

! Show NETCONF capabilities (YANG models)
Router# show netconf schema | include ietf-interfaces
  urn:ietf:params:xml:ns:yang:ietf-interfaces?module=ietf-interfaces&revision=2018-02-20

! Show operational state using YANG path (NETCONF-style)
Router# show yang operational-data /interfaces/interface[name='GigabitEthernet1']

! Show YANG model list
Router# show telemetry ietf subscription 1

YANG is the data modeling layer above NETCONF/RESTCONF. It provides the schema that these protocols use to encode data. Without YANG, NETCONF would lack a standardized data model, making interoperability difficult. YANG also underpins Model-Driven Telemetry (MDT), where devices push operational data defined by YANG models to collectors.

In a large enterprise, a network team manages hundreds of routers and switches across multiple data centers. They need to enforce consistent configuration baselines—for example, enabling SSH, setting NTP servers, and configuring SNMP traps. Using YANG models with NETCONF, they write a Python script that reads a CSV file of device hostnames and desired parameters, then pushes the configuration via NETCONF. The script uses the 'ietf-system' model to set NTP and DNS, and 'ietf-interfaces' to configure interface descriptions. This eliminates the risk of CLI typos and ensures every device matches the standard.

Another scenario: a service provider needs to collect interface utilization statistics from thousands of devices for capacity planning. Instead of polling SNMP OIDs individually, they use Model-Driven Telemetry (MDT) with YANG-defined paths. Devices push data (e.g., interface counters) to a collector at intervals or on change. This reduces CPU load on devices and provides near-real-time data. The YANG model 'ietf-interfaces' defines the exact counters (e.g., ifInOctets, ifOutOctets) that are streamed.

A common pitfall is using the wrong YANG model revision. Devices may support multiple revisions of the same model. If a client sends data conforming to an older revision, the device might reject it or misinterpret. Always check the device's capabilities and use the exact revision it advertises. Another issue: forgetting to commit changes when using the candidate datastore. The candidate datastore allows multiple edits before committing, but if the session ends without commit, changes are lost. In production, always implement error handling and commit confirmation.