Oktavia family · Carrier / SP
Oktavia for service providers
The same Oktavia closed loop applied to a provider network: a customer service is declared once and Oktavia distributes it to every PE and CE, applies the Cisco IOS XR core as a single network transaction and verifies the service came up.
1. What it is
Oktavia for service providers is the part of the platform that runs the core and edge of a provider network: the P routers and route reflectors in the core, the PEs at each point of presence, and the customer CEs. It is not a separate product: it is the same cycle of auditing, comparing against intent, proposing in the Digital Twin, approving, applying, verifying and auditing again, with a provider-specific service catalog.
It is tested in the lab with Cisco IOS XR (XRv9000 24.3) in the core and Cisco IOS on the customer CE.
| Role | Site type | Devices |
|---|---|---|
| P and route reflector | core | IOS XR core |
| PE | pop | IOS XR provider edge |
| CE | cliente (customer) | Customer device, Cisco IOS |
2. The approach
Intent per service, not per device
Intent is declared per service, in the style of L3SM and L2SM: a customer service is declared once —the customer, its sites or circuits and the contracted bandwidth— and Oktavia distributes it to every PE and CE involved. Nobody edits device by device.
Each customer's numbering plan is derived from its identifier: the customer AS, the RTs, the RD per PE, the /31 PE-CE links, the pseudowire EVI and the subnets. Two customers never collide, and the same customer is numbered the same way on every rollout.
Model-driven on IOS XR
IOS XR devices are managed over NETCONF with YANG models: the Cisco-IOS-XR-um-* models for configuration and the native operational models for state. No screen scraping.
Closed loop with a network transaction
The core is not changed device by device: every IOS XR enters a single transaction. If one rejects the change or verification fails, it is cancelled on all of them.
The provider tenant is recognized automatically
When an organization has IOS XR devices or P, PE or RR roles, Oktavia treats it as a provider network: the domains become Transport · Services · Security · Management (in an enterprise they are Campus · WAN · Security · Management) in Argos, Architecture, Telemetry, Home and the analyses, and the campus flows —VLANs, port-security, FlexVPN and the campus test network— are hidden. Other tenants are not affected.
3. Service catalog
Services are declared in the Configurator, each with its own desired configuration and its own compliance:
| Service | What it configures |
|---|---|
| IOS XR hardening | Device management and hardening: management VRF and ACL, SSH and NETCONF, SNMP, NTP, logging and banner. |
| IS-IS with Segment Routing | IS-IS level 2 underlay with Segment Routing MPLS (prefix-SID), TI-LFA and BFD, with authentication whose key lives in the vault. |
| Core BGP | BGP with a route reflector and the VPNv4 and L2VPN EVPN families; the EVPN family is added automatically when there are pseudowires. |
| L3VPN | Per customer: VRF, RT and RD, PE-CE eBGP with as-override and the site LAN on the CE. |
| L2VPN EVPN-VPWS | Point-to-point pseudowires, several per PE-CE link, on VLAN subinterfaces (EVI 1000 + id). |
| Contracted QoS | The bandwidth contracted per site or circuit, on the PE interface: police inbound and shape outbound (police where the platform cannot shape on a subinterface), with a dedicated pair of policies per contract. |
| Streaming telemetry | Model-driven telemetry over gRPC dial-out, on IOS XR and IOS XE, to the Oktavia collector. |
The customer side comes from the same service. The CE (Cisco IOS) part of the L3VPN and the pseudowires is generated from the same declaration as the PE part: there is no second intent to keep up to date.
4. The cycle and the Digital Twin
Core network lane
A core change is one transaction over every IOS XR at once:
- Validation in each IOS XR candidate configuration, as a dry run.
- Commit confirmed on all of them.
- Automatic verification: IS-IS adjacencies, core BGP sessions and xconnects up.
- Human confirmation of the change.
If an IOS XR rejects the commit or verification fails, the change is cancelled on all of them. CEs go through their own Digital Twin change, device by device.
Compliance per service
The desired YANG configuration of each service is compared with the running configuration, leaf by leaf, and each service gets its own result. State tests are added on top: IS-IS adjacencies, BFD and the provider BGP sessions.
5. Visibility
- Desired configuration of each IOS XR, per service.
- Topology with the core point-to-point links, the IS-IS layer and the pseudowires.
- Control plane: IS-IS neighbors with level, area and adjacency SID; BGP with its ASN; routing table with VPN labels and TI-LFA backups told apart from ECMP.
- Path across the MPLS L3VPN: ingress PE, VPN label and egress PE, in both directions, also on the Topology.
- Customer services: one page per customer with its L3VPNs and pseudowires, end-to-end state, QoS contract and diagram.
- Telemetry: CPU and memory, BGP sessions, IS-IS adjacencies and routing table size over SNMP, and a pseudowires section with the traffic and attachment-circuit state on each PE, where the contracted bandwidth is 100 %. Over streaming, IOS XR also sends xconnect state.
- Technical record with a customer services section: numbering plan, sites, circuits and QoS.
6. Argos on a provider network
Organization flows follow the organization's architecture. On a provider tenant, Argos offers:
| Flow | What it does |
|---|---|
| SP core (IOS XR) | Applies the core intent as a network change. |
| Customer pseudowires (EVPN-VPWS) | Shows the circuits with their state and adds a pseudowire: validates VLAN, subnet and endpoints, saves the intent and proposes the network change. |
| Customer QoS (contracted bandwidth) | Shows and changes contracts: validates, saves and proposes the change. |
The common tabs take on a provider meaning:
- Diagnosis and analysis per domain, Transport and Services.
- Connectivity test of a customer site from the CE: reachability to the PE, the PE-CE BGP session, the remote LAN across the L3VPN and the remote CE of the pseudowire.
- Enable telemetry with IOS XR streaming.
As everywhere else in the platform, no action that touches the network happens without a person approving it.
7. Local AI with provider context
The local AI answers, on the customer's own server, with the context of a provider network:
- The team's documents: design (HLD), runbooks, change procedure, security policy and circuits.
- The technical record per site.
- The IOS XR guides from xrdocs: telemetry and Converged SDN Transport.
- The RFCs of the technologies: RFC 4364 (L3VPN), RFC 4456 (route reflector), RFC 7432 (EVPN), RFC 8214 (EVPN-VPWS), RFC 8402 (Segment Routing), RFC 8667 (IS-IS with Segment Routing), RFC 1195 (IS-IS), and the TI-LFA documentation.
How it works is covered in the article Local AI with your company's context.
8. The Oktavia platform family
The service provider is one more platform in the family. The cycle and the platform are the same; what changes is how each one is accessed:
| Platform | Access | Typical use |
|---|---|---|
| Cisco IOS / IOS XE | SSH (CLI) and model-driven streaming (IOS XE) | Campus, WAN, customer CE |
| Cisco IOS XR | NETCONF / YANG | Provider core and PE |
| Cisco SD-WAN | Manager API | Software-defined WAN |
| Cisco Meraki | Dashboard API | Cloud-managed branches |
| Fortinet FortiGate | REST API | Perimeter security |
| Fortinet FortiSwitch | SSH | Campus |
| Juniper Junos | NETCONF | Security and routing |
Per-vendor coverage is in the technical sheet.
9. Coming soon
- On-demand SR-TE (ODN), with color per service.
- Data center integration with Cisco ACI.