Model Driven Programmability and Management Levels

What it is

Model driven programmability uses a formal data model to describe a device, and controller level and device level management are two places where you can apply it.

A data model gives every setting a defined name, type and place. Automation tools can then read and write those settings in a predictable way, without scraping CLI text.

Device level management talks to each box separately. Controller level management talks to one system that manages many boxes.

How it works

The model makes the data consistent, and the management level decides how far one call reaches.

The value of model driven programmability

• Structured data. Replies are JSON or XML with named fields, so a script reads a value by its key and not by its position in screen text.
• Consistency. The same model works across tools, languages and, with standard models, across vendors.
• Validation. The model defines types and ranges, so a bad value is rejected before it changes the device.
• Transactions. NETCONF can apply a change as a whole or not at all, and roll it back.
• Separation of configuration and state. The model marks what you can change and what is read only.
• Telemetry. Models also describe operational data that a device can stream out.

CLI scripting still works. Its weakness is that output formats change between releases, so the script that parsed text yesterday may break today.

Device level management

In device level management, your tool connects to each device and configures it directly, using the CLI over SSH, SNMP, NETCONF, RESTCONF or a vendor API.

Tools such as Ansible, ncclient and plain Python scripts often work at this level.

Controller level management

In controller level management, you tell a central controller what you want, and it configures the devices. Cisco examples are Catalyst Center, Meraki, ACI and the SD-WAN manager.

The same task at both levels

Suppose you must create a VLAN on 50 switches.

At device level, a script loops over 50 addresses, logs in to each, and sends the change. At controller level, you send one call or define one template, and the controller applies it to the group.

# device level: one call per switch
for switch in SWITCHES:
    push_vlan(switch, vlan_id=110, name="CAMERAS")

# controller level: one call to the controller
requests.post(CONTROLLER_URL + "/templates/deploy", json=payload)

The second call is illustrative. Every controller defines its own path and body, so check its documentation.

Mixing the two

Many networks use both. The controller handles day to day work, and device level access remains for troubleshooting, for features the controller does not cover, and for devices that it does not manage.

A caution applies here. A manual change on a device that a controller manages may be overwritten by the controller, or may make the device drift from the intended state. Decide which level owns each setting.

Model driven at both levels

Models help at both levels. At device level, YANG backed NETCONF and RESTCONF give structured access to a box. At controller level, the controller often uses its own models behind its REST API, and NSO uses YANG for both devices and services.