18.2 YANG Data Modeling Language (RFC 6020/7950) & Model Types

18.2 YANG Data Modeling Language (RFC 6020/7950) & Model Types

Core Blueprint Focus: Cisco 350-401 ENCOR v1.2 topic 6.3 (describe the high-level principles and benefits of a data modeling language, such as YANG) requires network engineers to understand data modeling constructs using YANG (Yet Another Next Generation). Candidates must master core YANG data modeling elements (leaf, leaf-list, container, list with key, typedef, grouping/uses, augment), distinguish configuration data (config true) from operational/state data (config false), interpret pyang tree outputs, and compare Vendor-Native, IETF Standard, and OpenConfig models.

Traditional network management suffered from unstructured, vendor-proprietary CLI outputs and fragmented SNMP MIBs. To enable programmatic network automation, the networking industry separated data modeling (schema definitions) from data encoding (serialization formats like XML or JSON) and transport protocols (NETCONF, RESTCONF, gNMI).

+---------------------------------------------------------------------------------------------------+
|                         THE MODEL-DRIVEN PROGRAMMABILITY STACK                                    |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  [ DATA MODELS ]        +--------------------+ +--------------------+ +------------------------+  |
|  (Schema & Semantics)   |   IETF Standard    | |  OpenConfig Model  | |  Cisco Native Model    |  |
|                         |  (RFC 8343 / 8344) | | (openconfig-intf)  | |(Cisco-IOS-XE-native)   |  |
|                         +--------------------+ +--------------------+ +------------------------+  |
|                                          \               |               /                        |
|                                           v              v              v                         |
|  [ PROTOCOLS ]          +--------------------+ +--------------------+ +------------------------+  |
|  (Operations & RPCs)    |  NETCONF (RFC 6241)| | RESTCONF (RFC 8040)| |     gNMI / gRPC        |  |
|                         +--------------------+ +--------------------+ +------------------------+  |
|                                   |                      |                        |               |
|  [ DATA ENCODINGS ]               v                      v                        v               |
|  (Wire Formats)         +--------------------+ +--------------------+ +------------------------+  |
|                         |     XML (eXtensible| |   JSON (JavaScript | |   Google Protocol      |  |
|                         |    Markup Language)| | Object Notation)   | |  Buffers (Protobuf)    |  |
|                         +--------------------+ +--------------------+ +------------------------+  |
|                                   |                      |                        |               |
|  [ TRANSPORT LAYERS ]             v                      v                        v               |
|                         +--------------------+ +--------------------+ +------------------------+  |
|                         |  SSH (TCP Port 830)| |HTTPS (TCP Port 443)| |HTTP/2 (TLS TCP 57500)  |  |
|                         +--------------------+ +--------------------+ +------------------------+  |
+---------------------------------------------------------------------------------------------------+

1. YANG Building Blocks & Modeling Constructs

YANG (RFC 6020 for YANG 1.0; RFC 7950 for YANG 1.1) is a declarative, strongly-typed data modeling language. It defines the hierarchical structure, constraints, syntax, and semantics of data transmitted over network management protocols.

The Four Fundamental Node Types

1. leaf: Represents a single, scalar data node containing a value but no child nodes (e.g., hostname, IP address, MTU, admin-status).
2. leaf-list: Represents an ordered array of scalar leaf nodes of a specific data type (e.g., a list of DNS server IP addresses or NTP server names).
3. container: Represents an interior grouping node used to organize related child nodes into a sub-tree hierarchy. A container holds no value of its own and requires no key.
4. list: Represents a sequence of structured list entries (like a database table). Each entry contains multiple child nodes and must define a mandatory key leaf that uniquely identifies each instance in the list (e.g., an interface list where name is the key).

module example-router-interfaces {
  yang-version 1.1;
  namespace "urn:enterprise:params:xml:ns:yang:router-interfaces";
  prefix "r-if";

  // 1. CONTAINER: Organizational grouping node
  container interfaces {
    description "Top-level container for all router interfaces";

    // 2. LIST with mandatory KEY: Sequence of interface records
    list interface {
      key "name";
      description "Interface entry uniquely keyed by its name";

      // 3. LEAF: Single scalar value
      leaf name {
        type string;
        description "Interface identifier, e.g., GigabitEthernet1";
      }

      leaf description {
        type string;
        description "Human-readable interface description";
      }

      leaf enabled {
        type boolean;
        default "true";
      }

      leaf mtu {
        type uint16 {
          range "64..9216";
        }
        default 1500;
      }

      // 4. LEAF-LIST: Array of scalar values
      leaf-list secondary-ip {
        type string;
        description "List of secondary IP addresses assigned to the interface";
      }
    }
  }
}

2. Advanced YANG Reusability: typedef, grouping, uses, and augment

YANG provides powerful modularity constructs to eliminate code duplication and allow modelers to extend existing schemas.

Custom Types: typedef

Defines a custom, reusable data type derived from built-in base types (such as string, int32, uint16, enumeration), applying constraints such as numerical ranges or regex patterns.

typedef ipv4-address {
  type string {
    pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
          + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
  }
  description "Standard dotted-decimal IPv4 address format validation";
}
typedef admin-state {
  type enumeration {
    enum up { value 1; }
    enum down { value 2; }
    enum testing { value 3; }
  }
}

Reusable Hierarchies: grouping and uses

• grouping: Declares a reusable block of nodes (similar to a class or struct definition in programming languages). A grouping creates no data nodes on its own.
• uses: Instantiates a previously declared grouping inside a container or list.

grouping endpoint-stats {
  leaf in-octets {
    type uint64;
    config false; // Operational state metric
  }
  leaf out-octets {
    type uint64;
    config false; // Operational state metric
  }
  leaf in-errors {
    type uint32;
    config false;
  }
}

container port-monitoring {
  uses endpoint-stats; // Clones in-octets, out-octets, and in-errors into this container
}

Schema Extension: augment and when

The augment statement injects new nodes into an existing local or imported foreign YANG model without altering the original module's source code. It frequently utilizes the when condition to conditionally apply extensions.

import ietf-interfaces { prefix if; }

augment "/if:interfaces/if:interface" {
  when "if:type = 'iana-if-type:ethernetCsmacd'";
  description "Augments standard IETF interfaces with Cisco-specific speed capabilities";
  
  leaf auto-negotiation {
    type boolean;
    default true;
  }
  leaf optical-wavelength-nm {
    type uint16;
  }
}

3. Configuration (config true) vs. Operational State (config false)

YANG establishes an absolute semantic boundary between what an administrator intends to configure versus the actual live status reported by device hardware.

+---------------------------------------------------------------------------------------------------+
|                    CONFIGURATION DATA VS. OPERATIONAL / STATE DATA                                |
+---------------------------------------------------------------------------------------------------+
|  Attribute             | Configuration Data (`config true`)    | State Data (`config false`)      |
| :--------------------- | :------------------------------------ | :-------------------------------- |
| **Default Setting**    | Default for all YANG statements       | Explicitly declared `config false;`|
| **Read / Write**       | Read-Write (RW)                       | Read-Only (RO)                     |
| **Administrator Role** | Explicitly set via CLI, NETCONF, REST | Generated by device OS and ASICs   |
| **Examples**           | IP address, OSPF cost, admin `enabled`| Packet drops, CRC errors, CPU %,   |
|                        | MTU, BGP peer password, descriptions  | BGP state (`Established`), Temp °C |
| **Datastore Presence** | In `running`, `startup`, `candidate`  | Dynamic; not in config datastores  |
| **NETCONF Retrieval**  | `<get-config>` or `<get>`             | `<get>` only                       |
| **RESTCONF Query**     | `?content=config` or `?content=all`   | `?content=nonconfig` or `all`      |
+---------------------------------------------------------------------------------------------------+

4. YANG Model Inspection with pyang

pyang is the canonical open-source Python tool used to validate, verify, and visualize YANG data models. The -f tree formatting option generates a clean ASCII representation of a module's hierarchical node tree.

Interpreting pyang -f tree Notation

$ pyang -f tree ietf-interfaces.yang
module: ietf-interfaces
  +--rw interfaces
  |  +--rw interface* [name]
  |     +--rw name                        string
  |     +--rw description?                string
  |     +--rw type                        identityref
  |     +--rw enabled?                    boolean
  |     +--ro oper-status                 enumeration
  |     +--ro last-change?                yang:date-and-time
  |     +--ro statistics
  |        +--ro discontinuity-time       yang:date-and-time
  |        +--ro in-octets?               yang:counter64
  |        +--ro in-unicast-pkts?         yang:counter64
  |        +--ro in-errors?               yang:counter32
  |        +--ro out-octets?              yang:counter64
  +---x reset-interface-stats
     |  +---w input
     |     +---w interface-name           string
     +--ro output
        +--ro status                      string

+---------------------------------------------------------------------------------------------------+
|                             PYANG TREE NOTATION SYMBOLS                                           |
+---------------------------------------------------------------------------------------------------+
|  Symbol Pattern | Node Category       | Meaning & Semantics                                       |
| :-------------- | :------------------ | :--------------------------------------------------------- |
| `+--rw`         | **Config Data**      | Read-Write node (`config true`). Configurable by user.     |
| `+--ro`         | **State Data**       | Read-Only node (`config false`). Operational metrics.      |
| `+---x`         | **RPC Operation**    | Remote Procedure Call action executable by client.         |
| `+---n`         | **Notification**     | Asynchronous event notification / telemetry stream.        |
| `*` (asterisk)  | **List / Leaf-list** | Multiple instance node (list entry or array elements).     |
| `[key_name]`    | **List Index Key**   | Indicates the leaf serving as the unique lookup key.       |
| `?` (question)  | **Optional Leaf**    | Node is optional (does not require mandatory assignment).  |
+---------------------------------------------------------------------------------------------------+

5. YANG Model Categories: Native vs. IETF vs. OpenConfig

To accommodate diverse operational environments, data models are divided into three primary categories:

+---------------------------------------------------------------------------------------------------+
|                         YANG MODEL CLASSIFICATION HIERARCHY                                       |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  1. CISCO NATIVE MODELS                                                                           |
|  - Namespace: Cisco-IOS-XE-native.yang, Cisco-IOS-XR-native.yang, cisco-nx-os-device.yang         |
|  - Scope: 100% feature coverage of proprietary Cisco CLI features (EIGRP, DMVPN, AVC, Flexible). |
|  - Structure: Closely mirrors Cisco IOS-XE hierarchical CLI syntax.                               |
|                                                                                                   |
|  2. IETF STANDARD MODELS                                                                          |
|  - Namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces, ietf-ip, ietf-routing                  |
|  - Scope: RFC-standardized baseline networking features (Interfaces, IP addressing, Syslog).      |
|  - Structure: Strict standards-body consensus; lowest common denominator across vendors.          |
|                                                                                                   |
|  3. OPENCONFIG MODELS                                                                             |
|  - Namespace: openconfig-interfaces.yang, openconfig-bgp.yang, openconfig-system.yang             |
|  - Scope: Multi-vendor consortium (Google, Microsoft, AT&T, Comcast) driven data models.         |
|  - Structure: Decoupled /config and /state containers; optimized for streaming telemetry.        |
+---------------------------------------------------------------------------------------------------+

Detailed Comparison of Model Types