📘Cisco DevNet Associate (200-901 DEVASC)

1. Introduction to Model-Driven Programmability

Model-Driven Programmability is a modern approach used to configure, monitor, and automate network infrastructure using structured data models and APIs instead of traditional command-line interfaces (CLI).

In traditional networks, engineers configure devices manually using CLI commands. This method has several limitations:

Difficult to automate
Hard to maintain consistency across many devices
Error-prone
Hard to integrate with software applications

Model-driven programmability solves these problems by using standardized data models to define how devices should be configured and how their data is structured.

This allows developers and network engineers to automate infrastructure using software tools and programming languages.

2. What is a Data Model in Networking?

A data model defines:

What configuration options exist on a device
How those options are structured
How they can be accessed programmatically

Instead of sending device-specific CLI commands, automation tools send structured data that follows a defined model.

Common formats used for model-driven programmability include:

JSON
XML
YAML

These formats allow infrastructure configurations to be treated like data objects, which software applications can easily read and modify.

3. Core Components of Model-Driven Programmability

Model-driven programmability uses several important components.

3.1 Data Models

A data model describes the structure of configuration and operational data.

It defines:

Configuration parameters
Hierarchical relationships
Data types
Allowed values

Example (simplified interface configuration model):

interface
 ├── name
 ├── description
 ├── enabled
 └── ip-address

Instead of typing multiple CLI commands, automation tools send structured configuration data that matches this model.

3.2 YANG Data Modeling Language

YANG is the most common modeling language used for network devices.

YANG defines:

Configuration data
Operational state data
Remote procedure calls
Notifications

Example simplified YANG model:

container interfaces {
   list interface {
      key "name";
      leaf name { type string; }
      leaf enabled { type boolean; }
   }
}

This model describes how interfaces should be represented in the device configuration.

Benefits of YANG:

Vendor-independent structure
Clear schema for automation tools
Supports validation and consistency

3.3 APIs Used in Model-Driven Networking

Once a data model is defined, APIs allow applications to interact with the device using that model.

Common APIs include:

RESTCONF

RESTCONF uses HTTP methods to interact with devices.

Operations include:

HTTP Method	Purpose
GET	Retrieve configuration or operational data
POST	Create new configuration
PUT	Replace configuration
PATCH	Modify configuration
DELETE	Remove configuration

RESTCONF usually uses:

JSON
XML

Example RESTCONF request:

GET /restconf/data/interfaces

NETCONF

NETCONF is another protocol used to manage network devices.

It uses:

XML encoding
Secure transport (SSH)

NETCONF supports operations such as:

Retrieve configuration
Edit configuration
Lock configuration
Commit changes

NETCONF works directly with YANG models.

3.4 Structured Data

Model-driven programmability uses structured data instead of unstructured CLI output.

Example CLI output:

GigabitEthernet1 is up
  IP address 192.168.10.1

Structured model-driven output:

{
 "interface": {
   "name": "GigabitEthernet1",
   "enabled": true,
   "ip-address": "192.168.10.1"
 }
}

Structured data allows programs to easily:

Parse data
Validate data
Modify configuration automatically

4. Why Model-Driven Programmability is Important

Model-driven programmability provides several major advantages in network automation.

5. Value of Model-Driven Programmability

5.1 Consistent Configuration

Using models ensures that device configurations follow the same structure across all devices.

Example:

A configuration automation script can apply the same interface configuration to:

routers
switches
firewalls

because the data model structure remains consistent.

This reduces configuration differences across the infrastructure.

5.2 Easier Automation

Because configurations are structured as data, they can easily be used by automation tools.

Automation systems can:

Generate configurations automatically
Deploy configurations to hundreds of devices
Update configurations programmatically

Example IT automation workflow:

Developer creates network configuration template
Automation tool generates JSON configuration
Script sends configuration using RESTCONF
Device updates its configuration

This process allows large-scale infrastructure automation.

5.3 Reduced Human Errors

Manual CLI configuration often leads to mistakes such as:

Typing errors
Incorrect command order
Missing parameters

Model-driven APIs allow validation before applying configuration.

Example:

If a YANG model requires an IP address format, the system can reject invalid input.

This reduces configuration failures.

5.4 Faster Infrastructure Deployment

Automation systems can deploy network configurations very quickly.

Example IT scenario:

A company deploys a new application that requires:

VLAN configuration
interface configuration
routing policies
firewall rules

Instead of configuring each device manually, automation tools use model-driven APIs to deploy all configurations automatically.

This reduces deployment time from hours to minutes.

5.5 Better Integration with Applications

Modern infrastructure often needs to integrate with applications such as:

CI/CD pipelines
monitoring systems
cloud orchestration platforms

Model-driven APIs allow applications to interact with network infrastructure easily.

Example integration:

CI/CD pipeline process:

Application is deployed
Automation tool calls network API
Load balancer configuration is updated
New servers are added to the network

This allows network infrastructure to become part of automated software workflows.

5.6 Machine-Readable Data

Model-driven programmability provides machine-readable outputs.

Unlike CLI output, structured data is easier for software tools to process.

Benefits include:

easier parsing
reliable data extraction
improved monitoring systems

Example:

Monitoring software can retrieve device statistics via RESTCONF and automatically analyze network performance.

5.7 Vendor Standardization

Many networking vendors support standardized models.

Common model standards include:

OpenConfig
IETF YANG models

These standards allow automation tools to manage devices from different vendors using the same model structure.

This reduces vendor dependency.

5.8 Supports Infrastructure as Code (IaC)

Model-driven programmability allows infrastructure configurations to be managed like software code.

This enables:

version control
configuration templates
automated deployment pipelines

Example workflow:

Network configuration stored in Git repository
Automation tool reads configuration model
Script sends configuration to devices
Changes are tracked and version controlled

This approach improves change management and reliability.

6. Example IT Scenario Using Model-Driven Programmability

Example scenario in an IT environment:

A company operates a large data center network with hundreds of switches.

A network automation system performs the following:

Retrieves switch interface status using RESTCONF
Uses structured JSON data to analyze link health
Automatically disables faulty interfaces
Sends new configuration to switches using NETCONF
Logs configuration changes in a version control system

Without model-driven programmability, performing this automation would be very complex using CLI commands.

7. Comparison: Traditional CLI vs Model-Driven Automation

Feature	CLI-Based Configuration	Model-Driven Programmability
Configuration method	Manual commands	Structured data models
Automation	Difficult	Easy
Data format	Unstructured text	Structured (JSON/XML)
Error checking	Limited	Built-in validation
Integration	Hard	Easy with APIs
Scalability	Limited	High

8. Key Technologies to Remember for the DEVASC Exam

You should understand these technologies related to model-driven programmability:

Data Modeling

YANG

Management Protocols

NETCONF
RESTCONF

Data Formats

JSON
XML
YAML

Model Standards

OpenConfig
IETF YANG models

9. Key Exam Points to Remember

For the DEVASC exam, remember these key ideas:

Model-driven programmability uses data models instead of CLI commands.
YANG defines the structure of configuration and operational data.
NETCONF and RESTCONF are protocols used to interact with devices using models.
Data is exchanged in structured formats such as JSON or XML.
It enables network automation, scalability, and integration with software systems.
It reduces manual configuration errors.
It supports Infrastructure as Code (IaC) and DevOps workflows.

✅ Simple Summary

Model-Driven Programmability allows network infrastructure to be managed using structured data models and APIs instead of manual CLI commands.

It enables automation, consistency, faster deployments, and integration with software systems, making it a key technology for modern programmable networks and an important concept for the Cisco DevNet Associate (200-901 DEVASC) exam.