IP Network Automation with Nokia NSP
What this domain tests
The automation domain tests Nokia Network Services Platform (NSP) as a model-driven controller for SR OS. Expect questions on intent-based service provisioning, NETCONF/YANG and gNMI interfaces, workflow orchestration, and closed-loop assurance for VPRN services.
Core rules
- NSP communicates with SR OS using model-driven interfaces; YANG models define the configurable objects, including VPRN, SAP, and BGP.
- A service template captures intent: service ID, customer, RD/RT, SAP encapsulation, and routing protocol. Variables are resolved per deployment.
- Workflow Manager sequences validation, configuration, and verification. Good workflows are idempotent: re-running them should not create duplicate services.
- Telemetry and fault data feed closed-loop actions, but automation must respect maintenance windows and rollback.
- NSP can provision multi-vendor and multi-layer services, but SR OS-specific behavior still depends on the correct YANG model version.
Worked example
A template for VPRN 5000 uses variables customer_id and pe_loopback. The RD is built as pe_loopback:5000 and the RT as 65000:5000. NSP renders the intent into device-specific YANG payloads, pushes them to PE1 and PE2, then reads back the operational state. If PE2 already has VPRN 5000 with a different RT, the workflow should fail validation rather than overwrite it.
Traps
Do not assume CLI commands are idempotent. Do not ignore model version differences between SR OS releases. A successful commit does not prove service state; verify BGP and SAP operational status.