NSO Service-Modelle vs. rohes RESTCONF - was Cursor wirklich kostet
Frontier-LLMs können RESTCONF lesen. Brauchst du NSO-Service-Modelle noch? Ein Lab-Vergleich zu Agent-Turns und Kontextgröße beim BGP-AS-Wechsel.
19 Minuten Walkthrough - Nokia-SR-OS-Lab mit BGP Route Reflector, NSO Service Packages und MCP.
Die Frage klingt naiv: Wenn Claude und Cursor heute RESTCONF-APIs lesen und konfigurieren können - warum soll ich noch Services in Cisco NSO modellieren?
Ich habe das nicht theoretisch diskutiert, sondern in meinem Nokia-SR-OS-Dreieck (R1/R2/R3 plus NetSim-Simulatoren) durchgespielt. R2 ist Route Reflector, R1/R3 Clients. Die Peering-Konfiguration steckt in NSO-Service-Packages: YANG rein, XML-Template raus.
Was Cursor ohne Service-Modelle machen würde
Ich habe Cursor gebeten, einen konkreten Change durchzurechnen: die gemeinsame iBGP-AS (65000) ändern.
Ohne Service-Model: - Inventar der Geräte holen oder merken - pro Router den kompletten BGP-Subtree als JSON ziehen (Nokia YANG, NetSim, IOS-XR-Formen im Chat) - jedes Leaf einzeln patchen - Sync prüfen, Drift fixen, bei Fehlern nochmal
Mit Service-Model: - ein MCP-Call für die AS am Reflector - sieben kleine Calls für die Clients - kleines JSON rein, kleines JSON raus - Rollback = Service-Instanz löschen
Cursors eigene Schätzung in der Session: etwa drei- bis fünfmal weniger Agent-Turns mit dem modellierten Pfad. Bei drei Routern merkst du das kaum. Bei zweihundert wird es relevant - nicht wegen des Euro-Betrags pro Token (den ignorieren viele Teams gerade), sondern wegen Kontextgröße und Fehlerrate pro Turn.
Wann ein Service-Model lohnt - und wann nicht
Drei Szenarien aus dem Video:
A - Parameter-Tweak: AS für alle ändern. Ein Default-Wert im Template, kein extra Input-Feld. Ein Zeiler im MCP-Tool reicht.
B - Reflector-only: Nur die RR-AS anpassen. Immer noch im gleichen Design-Rahmen.
C - eBGP statt iBGP: Das ist kein Parameter-Change mehr. Du musst das Service-Model neu designen lassen. Cursor kann das - aber das ist ein größerer Prompt, kein schneller Fix.
Der Punkt: NSO übernimmt CRUD auf dem modellierten Service. Cursors Job ist das Modellieren und die MCP-Werkzeuge drumherum - nicht jedes Mal die volle Device-YANG-Hierarchie in den Chat zu laden.
Lab-Kontext
Das Video baut auf Lab 1 der NSO-SROS-Serie auf (IS-IS + iBGP RR komplett über MCP provisioniert). Hier geht es um die Architekturfrage danach: lohnt sich der Modellierungsaufwand?
Stack: NSO 6.x, alu-sr NED, NetSim, eigener RESTCONF-MCP-Server (~147 Tools), Cursor IDE.
Mehr zu KI-Beratung und Netzwerkautomatisierung: guandeng.de/ai.