From Clicks to Code: Optical Network Automation Journey at GARR#

Matteo Colantonio, GARR (Italian research and education network)

• Why: Physical-layer transport (optical circuits, transponders, ROADMs) is the least-automated part of most networks, and this is a rare honest account of why the usual automation stack fails there and what actually works. Directly relevant to anyone with DC/WAN interconnect responsibilities.
• What: GARR's progression from Ansible/AWX and the vendor controller's northbound API to a workflow-orchestrator architecture that talks directly to optical devices, now in early production use.
• How: Ansible handled basic transponder upgrades but collapsed on complex logic — restarting cards one-by-one and verifying service recovery required three nested YAMLs with include statements. The vendor controller API was a stripped-down version of the GUI: missing key features, and useless for circuits crossing multiple line systems (mixed-platform ROADM metro regions). The pivot: build abstract service models plus Python clients speaking the same southbound interfaces the vendor controller uses (RESTCONF, TL1 shell for ROADMs), separating intent from device-specific configuration.
• Where applicable: GARR-specific in topology (research backbone, mixed optical platforms), but the lessons — vendor NBIs as a bottleneck, direct device control, incremental automation starting with critical services — transfer to any optical/WAN environment. The observation that optical networks' GUI-centric (not CLI-centric) history changes the automation starting point is a genuinely useful framing.