IP Network Automation (Network Services Platform)
This domain tests automation with Nokia’s Network Services Platform (NSP): model-driven management, YANG models, NETCONF and gRPC, telemetry, templates, workflows, service intent, and closed-loop assurance. Expect questions about how an intent becomes device configuration and how drift is detected.
Core rules
- NSP is multivendor and model-driven. It validates service intent, renders device-specific configuration, and commits through protocols such as NETCONF or gRPC.
- YANG defines the data model; JSON or XML carries the payload. Model version must match the device and NSP adapter.
- Automation should be idempotent: applying the same intent twice must not create duplicate state.
- Telemetry subscriptions stream operational state; assurance compares actual state with intent and can trigger remediation.
- Direct device changes create drift. NSP must reconcile or re-deploy intent.
Worked example
An engineer creates a VPRN intent in NSP with a route distinguisher, route target, and two interfaces. NSP validates the intent against the YANG model, renders SR OS MD-CLI or NETCONF payloads, and commits. It then subscribes to telemetry for interface and BGP state. If a later manual change removes a route target, assurance reports drift and the workflow re-applies the intent. A dry-run before commit would show the exact configuration delta.
Traps that cost marks
- Treating NSP as only a GUI and ignoring its model-driven workflow.
- Skipping dry-run or rollback planning.
- Assuming automation is the same as a script with no validation.
- Ignoring model or software version mismatches.
Key points
- NSP turns intent into model-validated configuration.
- NETCONF/gRPC are transport and management mechanisms.
- Idempotency prevents duplicate service state.
- Telemetry enables assurance and closed-loop control.
- Manual changes cause drift that must be reconciled.