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

CCNP Enterprise ENCOR 350-401

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Enterprise Architecture & Hierarchical Design

1.1 Enterprise Network Design Models & Hierarchical Campus Architecture 1.2 On-Premises, Cloud & Hybrid Infrastructure Deployment Models 1.3 Hardware Switching Architecture & Packet Forwarding

2 Chapter 2: Enterprise Quality of Service (QoS)

2.1 QoS Components: Classification, Marking & Trust Boundaries 2.2 QoS Policy: Queuing, Shaping, Policing & Interpreting MQC Output

3 Chapter 3: Software-Defined WAN (Catalyst SD-WAN)

3.1 Cisco Catalyst SD-WAN Architecture & Orchestration 3.2 SD-WAN Policies, Traffic Engineering & Application-Aware Routing

4 Chapter 4: Software-Defined Access (Catalyst SD-Access)

4.1 Catalyst SD-Access Fabric Architecture & Plane Separation 4.2 Cisco TrustSec, Security Group Tags (SGT), SXP & MACsec

5 Chapter 5: Device & Data Path Virtualization

5.1 Server & Network Device Virtualization 5.2 VRF-Lite & Virtual Routing Multi-Tenancy 5.3 GRE & IPsec Tunnel Virtualization Mechanics

6 Chapter 6: Network Virtualization & Overlay Technologies

6.1 LISP Architecture & EID-to-RLOC Mapping Mechanics 6.2 VXLAN & EVPN Overlay Architecture

7 Chapter 7: Layer 2 Infrastructure & Switching

7.1 VLANs, 802.1Q Trunking & VTPv3 7.2 Spanning Tree Protocol Mechanics 7.3 Advanced STP Protection Mechanisms 7.4 EtherChannel Link Aggregation

8 Chapter 8: Layer 3 Routing Foundations & EIGRP

8.1 IP Routing Foundations & Administrative Distance 8.2 Enhanced Interior Gateway Routing Protocol (EIGRP)

9 Chapter 9: OSPFv2 & OSPFv3 Operations

9.1 OSPFv2 Architecture & Neighbor State Machine 9.2 OSPF LSA Types & Multi-Area Design 9.3 OSPFv3 for IPv4 and IPv6 Address Families

10 Chapter 10: Border Gateway Protocol (BGP)

10.1 BGP Architecture, Neighbor States & Peering 10.2 BGP Path Attributes & Best Path Selection Algorithm

11 Chapter 11: Policy-Based Routing & Route Redistribution

11.1 Policy-Based Routing (PBR) & Route Maps 11.2 Route Redistribution & Loop Prevention

12 Chapter 12: IP Services & High Availability

12.1 First Hop Redundancy Protocols (HSRP, VRRP & GLBP) 12.2 Network Time Protocol (NTPv4) & Precision Time Protocol (PTP) 12.3 Network Address Translation (NAT/PAT) & VRF-Aware NAT

13 Chapter 13: IP Multicast Operations

13.1 IP Multicast Addressing, Group Management (IGMPv1/v2/v3) & IGMP Snooping 13.2 Protocol Independent Multicast (PIM-SM, PIM-SSM & Bidir-PIM) 13.3 Rendezvous Point (RP) Distribution Mechanisms

14 Chapter 14: Network Assurance & Monitoring

14.1 Diagnostic Utilities, Conditional Debugging & Path MTU Discovery 14.2 Syslog Architecture, Logging Facilities & Severity Levels 14.3 SNMPv1/v2c/v3 Security & Flexible NetFlow (FNF) Architecture 14.4 Switched Port Analyzer (SPAN, RSPAN, ERSPAN) & IP SLA Object Tracking

15 Chapter 15: Catalyst Center Assurance & Controller Operations

15.1 Cisco Catalyst Center (DNA Center) Assurance & AI Network Analytics 15.2 Cisco Catalyst Center Device Onboarding & Software Image Management (SWIM)

16 Chapter 16: Enterprise Security & Access Control

16.1 Device Hardening, AAA Architecture & RADIUS/TACACS+ 16.2 Access Control Lists (ACLs) for Infrastructure Security 16.3 Control Plane Policing (CoPP) & Control Plane Protection (CPPr) 16.4 Layer 2 Infrastructure Security Features 16.5 IEEE 802.1X Port-Based Authentication & MAB

17 Chapter 17: Threat Defense & API Security

17.1 Enterprise VPN Technologies (DMVPN Phase 1/2/3 & FlexVPN) 17.2 Next-Generation Threat Defense & Secure Access Service Edge (SASE)

18 Chapter 18: Network Automation, Programmability & Data Modeling

18.1 Python Fundamentals for Network Engineers & Cisco Libraries 18.2 YANG Data Modeling Language (RFC 6020/7950) & Model Types 18.3 REST API Architecture, HTTP Verbs, Security & Cisco Controller APIs 18.4 Model-Driven Telemetry (MDT) & NETCONF/RESTCONF Operations

19 Chapter 19: Orchestration, EEM & AI Operations

19.1 Configuration Management & Infrastructure as Code (Ansible & Terraform) 19.2 Cisco Embedded Event Manager (EEM) & Intent-Based Networking

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

Key Takeaways Explain This Topic AI

YANG (RFC 6020 / RFC 7950) is a declarative, hierarchical data modeling language that defines the schema, constraints, data types, and RPC operations for NETCONF, RESTCONF, and gNMI protocols.

YANG structural building blocks consist of leaf (single scalar value), leaf-list (ordered array of scalars), container (hierarchical grouping with no key), and list (multi-instance record table uniquely indexed by a mandatory key leaf).

Modularity and extensibility in YANG are achieved through typedef (custom constrained types), grouping and uses (reusable node trees), and augment (conditionally injecting new nodes into existing external schemas).

YANG strictly differentiates between configuration data (config true, read-write state managed by network administrators) and operational/state data (config false, read-only hardware counters, sensor readings, and protocol statistics).

YANG models are classified into three major tiers: Vendor-Native models (e.g., Cisco-IOS-XE-native.yang with 100% CLI feature parity), IETF Standard models (e.g., ietf-interfaces.yang defining vendor-neutral baselines), and OpenConfig models (e.g., openconfig-interfaces.yang providing operator-driven cross-vendor consistency).

Last updated: August 2026

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

leaf : Represents a single, scalar data node containing a value but no child nodes (e.g., hostname, IP address, MTU, admin-status).

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).

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.

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` |
+---------------------------------------------------------------------------------------------------+

Loading diagram... YANG Model Tree and pyang Node Notation

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

Attribute Cisco Vendor-Native Models IETF Standard Models OpenConfig Models
Governing Body Cisco Systems Inc. Internet Engineering Task Force OpenConfig Working Group
Model Example Cisco-IOS-XE-native.yang ietf-interfaces.yang (RFC 8343) openconfig-interfaces.yang
Feature Depth 100% Complete (Full CLI parity) Baseline standard features Broad routing/switching features

Multi-Vendor Support Cisco platforms only Any RFC-compliant vendor Participating vendors (Cisco, Arista, Juniper)

Structure Paradigm Mirrors show running-config CLI Modular RFC abstractions Strict /config vs /state separation

Primary Use Case Deep Cisco feature automation (QoS, DMVPN, HSRP) Basic multi-vendor interface & IP provisioning Unified cross-vendor telemetry & configuration