3 Network Controllers and Intent-Based Management

How network controllers coordinate a network

A Network controller gathers information about a network, makes or coordinates decisions, and communicates changes to network devices or other systems. It commonly connects to Northbound interfaces, used by applications, orchestration systems, and operators, and Southbound interfaces, used to read device state and configure network elements.

Controllers may combine topology and inventory data, policy evaluation, resource allocation, configuration generation, telemetry processing, and assurance. For example, a controller might receive a request to connect two sites, select an available path, configure the participating devices, and monitor whether connectivity persists.

A controller is often called centralized because it offers a unified view and point of administration. This does not require the software to run on one server: it can be distributed across several machines for capacity and resilience while appearing as one logical control system. Some network functions also remain distributed among devices, which may continue forwarding traffic if their controller connection is interrupted. The effects of a controller outage depend on the architecture and the function being controlled.

Controller-based design separates intent or service-level requests from device-level implementation. A controller can translate a higher-level request into configurations for multiple devices, reducing repetitive device-by-device work. The translation depends on the platform’s data models, supported devices, and implementation logic; a controller cannot provide an outcome if the network lacks the necessary resources or capabilities.

Intent and related management concepts

Intent-based management raises the abstraction above device configuration. The IETF defines Intent as an operational goal or outcome expressed declaratively, without specifying how to implement it. Intent says what the network should accomplish, not which device commands or steps to use.

For example, “Keep traffic between the research and data-center networks isolated” describes a desired outcome. Listing VLAN assignments, interface commands, and access-control entries describes an implementation plan rather than the intent itself.

Related management concepts differ in what they express:

• A configuration specifies settings on a device or service.

• A policy specifies rules that govern behavior, often in an event-condition-action form.

• A service model describes a service and its attributes; a system must still determine how to instantiate it using network resources.

• Intent expresses a desired outcome and relies on a management system to determine and maintain a suitable implementation.

An abstract-looking API request does not by itself make a system intent-based. The key distinction is whether the system interprets a desired outcome and determines how to achieve and assure it, rather than merely accepting a preselected set of configuration steps.

The intent lifecycle and its safeguards

A typical intent-based workflow has five stages:

1. Ingest and validate: Accept an operator’s request, check its syntax and meaning, and identify missing or conflicting requirements.

2. Translate and plan: Map the goal to network resources, policies, and device-level changes. Planning may need to account for capacity, topology, security constraints, and priorities.

3. Fulfill: Apply the planned changes, often coordinating changes across multiple devices or services.

4. Assure: Observe network state and service outcomes, compare them with the requested goal, and report whether the goal is being met.

5. Reconcile: If observed state diverges from desired state, notify an operator or take corrective action according to the system’s permissions and safety controls.

This process forms a feedback loop: applying configuration is not proof of success, so the system must also evaluate operational results. Intent fulfillment refers to the functions that achieve goals; Intent assurance refers to the functions that check continued compliance. Intent drift occurs when a network that once met a goal later stops meeting it.

Automation should be bounded by validation, authorization, change review, and recovery procedures. A controller may have broad access to network devices, so an incorrect request or faulty translation can affect more than one device. For consequential changes, use previews or staged deployment when available, and ensure that the resulting state can be checked and recovered.

Working safely with controller platforms

Controller platforms vary in terminology and capabilities, but a disciplined workflow helps manage changes safely.

1. Learn the platform’s model. Identify how it represents devices, sites, interfaces, policies, services, and desired state. Check which models and operations are supported for the target network.

2. Inspect before changing. Read current inventory, topology, configuration, and operational state. Confirm that the controller’s view is current enough for the planned operation.

3. Authenticate and scope access. Use approved credentials and the least privilege needed. Protect tokens and secrets; avoid embedding them in scripts, logs, or source control.

4. Use the API deliberately. Consult the platform’s API documentation for endpoints, request formats, status codes, pagination, rate limits, and asynchronous job behavior. Distinguish a request being accepted from the requested change completing successfully.

5. Validate and preview. Check inputs and dependencies. Where supported, use a dry run, plan, or change preview before committing changes.

6. Apply in manageable stages. Start with a limited scope, then expand when verification succeeds. Account for retries and partial failures; repeating an operation should not unintentionally create duplicate resources.

7. Verify outcomes. Query both configuration and operational state. Check the requested service or behavior, not only whether the API returned success.

8. Record and recover. Keep an audit trail of the request, result, and relevant state. Know how to roll back or reconcile the change before automating it broadly.

For example, an operator seeking a new isolated connection between two sites might submit a service-level request through a controller API. The controller could validate the site identifiers and isolation requirement, determine available resources, configure the required network elements, and expose deployment status. The operator should then verify that the service is operational and that traffic isolation works as intended. Actual request formats and controller behavior are platform-specific.

YANG provides a standardized way to model network configuration and state. NETCONF and RESTCONF provide protocols for interacting with YANG-modeled data. These mechanisms support programmatic management, but using them alone does not make an operation intent-based; the abstraction and outcome assurance depend on the management system built around them.