YANG

YANG enables model-driven programmability by providing a precise, machine-readable contract between network clients and servers. Unlike unstructured CLI scraping, YANG models define the exact syntax and semantics of every configurable element.

• Structured Data: Models define a strict tree hierarchy of containers, lists, and leaf nodes.
• Type Safety: Each leaf is bound to a specific data type (e.g., inet:ipv4-address, uint16), preventing invalid configurations.
• Single Source of Truth: The YANG model serves as the definitive API specification, from which NETCONF, RESTCONF, and gRPC interfaces are derived.

YANG cleanly separates configuration data from operational state data using the config true/false statement. This distinction is fundamental to declarative intent-based networking.

• Config (config true): The writable, intended state of the device, such as interface IP addresses or BGP peer settings.
• State (config false): Read-only data reflecting the device's actual running status, including interface counters, temperature sensors, and protocol adjacency tables.
• Unified Tree: Both config and state are exposed in a single, coherent data tree, allowing operators to compare intended versus actual state for drift detection.

YANG promotes modularity through typedefs and groupings, preventing duplication and ensuring consistency across large, multi-vendor data models.

• Typedef: Defines a custom data type derived from a base type with added constraints. For example, a vlan-id typedef restricts a uint16 to the range 1–4094.
• Grouping: A reusable block of schema nodes that can be referenced via the uses statement. Common structures like an IP prefix or a QoS policy can be defined once and instantiated in multiple places.
• Augmentation: External modules can extend existing models without modifying the original, enabling vendor-specific extensions to standard models like ietf-interfaces.

Beyond static data, YANG models define executable Remote Procedure Calls (RPCs) and asynchronous notifications for event-driven network management.

• RPC: Defines a parameterized operation that a server exposes. For example, an activate-license RPC takes a license key as input and returns a success or error status.
• Action: An operation bound to a specific data node instance, such as reset-counters on a particular interface.
• Notification: Defines an event that the server can push to subscribed clients, such as a link-down alert with the interface name and timestamp.
• YANG 1.1 introduced the action statement, clarifying the distinction between global operations and instance-specific operations.

YANG provides a rich constraint language that enforces data integrity at the model level, catching configuration errors before they are committed to a device.

• must Statement: An XPath expression that must evaluate to true for the data to be valid. For example, a must constraint can enforce that an MTU value does not exceed the parent interface's maximum.
• when Statement: Makes a node conditional on an XPath expression, dynamically hiding or disabling irrelevant configuration branches.
• unique Statement: Enforces uniqueness across one or more descendant leafs within a list, such as ensuring no two VLANs share the same ID.
• range and length: Restrict numeric and string values directly on type definitions.

YANG supports robust module lifecycle management through semantic versioning, import dependencies, and submodules, enabling multi-vendor interoperability.

• revision Statement: Tracks the version history of a module with a date stamp and description of changes.
• import and include: import references definitions from an external module, while include pulls in a submodule that shares the same namespace.
• Backward Compatibility: YANG 1.1 introduced the non-backwards-compatible extension to signal breaking changes, allowing clients to gracefully handle model updates.
• YANG Catalog: A public registry maintained by the IETF and industry bodies that indexes standardized and vendor-specific YANG modules for discovery.

A mechanism defined in RFC 8528 that allows one YANG module to reference and embed the entire schema tree of another module at a specific mount point. This is essential for modular device architectures.

• Use Case: Mounting line-card-specific YANG modules under a chassis controller module
• Scope: Each mount point creates an independent schema namespace
• Discovery: Clients query the mount point to retrieve the mounted schema tree
• Relationship: Enables recursive composition of device schemas without duplication

Defined in RFC 8525, YANG Library provides a standardized mechanism for a server to advertise the complete set of YANG modules, submodules, datastores, and schema mount points it supports.

• Content: Lists module name, revision, namespace, and conformance type
• Datastore Mapping: Associates each module with the datastores where it is implemented
• Dynamic Updates: YANG Library content changes when modules are loaded or removed at runtime
• Client Use: Enables automated tooling to discover device capabilities before issuing configuration