Network Intent

A network intent specifies the desired outcome without prescribing the specific configuration commands or device-level procedures required to achieve it. This decouples business policy from vendor-specific implementation details.

• What, not How: An intent states 'Ensure HIPAA compliance for this traffic' rather than 'Configure ACL 101 on interface Gi0/1.'
• Idempotency: The system continuously enforces the declared state, correcting any drift automatically.
• Portability: The same high-level intent can be applied across heterogeneous hardware from different vendors.

An intent must contain precise, quantifiable metrics that allow the closed-loop assurance system to validate compliance continuously. Vague requirements are not actionable.

• Latency Thresholds: 'Intra-pod traffic must not exceed 5ms round-trip.'
• Availability Guarantees: 'Service must maintain 99.999% uptime over a rolling 30-day window.'
• Path Constraints: 'Traffic must never transit through geographic region X.'
• Measurable KPIs: These SLOs serve as the ground truth for the intent assurance loop.

A network intent is not a one-time configuration push. It establishes a persistent control loop that constantly compares the network's actual state against the declared intent.

• Telemetry Ingestion: Streaming high-frequency metrics from all devices under management.
• Drift Detection: Algorithms identify any divergence between the intended and operational state.
• Automated Remediation: The system triggers pre-defined remediation workflows to restore compliance without a human ticket.
• State Machine: The intent exists in a formal lifecycle, transitioning between states like 'Fulfilled,' 'Drifted,' and 'Remediating.'

Multiple intents can coexist, but they must be structured within a policy continuum that defines precedence and resolves contradictions algorithmically.

• Business Intent: Highest level, e.g., 'Prioritize real-time trading traffic.'
• Operational Intent: Translates business goals into technical constraints.
• Conflict Resolution: If two intents compete for the same bandwidth, a priority-based or negotiation-based arbiter decides the outcome.
• Pre-Deployment Validation: The intent validation engine checks for logical inconsistencies before any configuration is synthesized.

Intents are expressed using standardized, abstract data models (typically YANG-based) rather than proprietary command-line interfaces. This ensures the intent engine can synthesize configurations for any compliant device.

• Schema-Driven: Intents conform to a strict, machine-readable schema.
• Intent-Based APIs: Northbound interfaces allow business applications to declare requirements using RESTCONF/NETCONF.
• Translation Layer: The intent translation function maps the abstract model to device-specific syntax for Cisco, Juniper, Arista, etc.
• No Screen Scraping: Eliminates the fragility of CLI parsing.

A network intent has a formal, managed lifecycle from creation to decommissioning, governed by an intent state machine. It is not a static configuration file.

• Creation & Validation: The intent is authored and checked for feasibility.
• Fulfillment: The system orchestrates resources and pushes synthesized configurations.
• Assurance: Continuous monitoring ensures the intent remains compliant.
• Modification & Retirement: Intents can be dynamically updated or safely removed, with the system automatically cleaning up the underlying configurations.

The algorithmic process of converting a declarative business policy into device-specific, low-level configurations. This is the bridge between business intent and network configuration synthesis.

• Ingests abstract data models (YANG, TOSCA)
• Outputs vendor-specific CLI, NETCONF, or RESTCONF payloads
• Must resolve dependencies across heterogeneous hardware
• Example: Translating 'prioritize voice traffic' into DSCP marking policies across Cisco, Juniper, and Nokia infrastructure simultaneously

A continuous validation loop that verifies the network's operational state matches the declared intent. This is the monitoring and correction half of the closed-loop system.

• Ingests streaming telemetry collection at sub-second intervals
• Compares real-time state against Service-Level Objectives (SLOs)
• Detects intent drift and triggers automated remediation
• Example: A 5G slice defined for <10ms latency is continuously measured; if latency spikes to 12ms, the assurance engine flags a violation and initiates a remediation workflow

An algorithmic mechanism that detects and resolves overlapping or contradictory intents. As multiple business units declare competing policies, the system must arbitrate.

• Uses priority-based or negotiation-based arbitration logic
• Prevents resource starvation from conflicting bandwidth guarantees
• Operates during the intent validation phase before deployment
• Example: Finance declares 'all traffic must be encrypted' while Trading declares 'ultra-low latency, no crypto overhead'—the resolver must reconcile these based on a defined policy continuum hierarchy

The overarching control framework that eliminates human intervention from network operations. It combines intent fulfillment and intent assurance into a self-regulating system.

• Observe: Collect real-time telemetry
• Orient: Analyze against declared intent and SLOs
• Decide: Determine if corrective action is required
• Act: Execute remediation workflows automatically
• Example: A sudden traffic surge triggers automatic bandwidth reallocation across network slices without a network operations center ticket being filed

A hierarchical framework structuring network policies from abstract business goals down to concrete device configurations. This is the ontological backbone of intent-based systems.

• Business Intent: 'Ensure PCI compliance for payment traffic'
• Operational Policy: 'Segment payment systems into isolated VLANs'
• System Rules: 'Apply ACL 110 to block non-payment ports'
• Device Config: ip access-list extended PCI-SEGMENT...
• Each layer inherits constraints from above while adding technical specificity

Northbound interfaces allowing applications to declare network requirements using abstract data models rather than device-level protocols. These are the integration points for business systems.

• Expose intent declaration endpoints (gRPC, REST)
• Use declarative data models, not imperative commands
• Enable CI/CD pipelines to treat network as code
• Example: A Kubernetes pod declares a network intent for 'low-latency, encrypted east-west traffic' via a Custom Resource Definition, and the IBN controller provisions it automatically