Zusammenfassung

  • AI4AN schlägt vor allem vor, ein LLM Automatisierungssoftware entwickeln und testen zu lassen, die später als Autonomic Service Agent verteilt wird, statt ausschließlich ein Modell live über Netzänderungen entscheiden zu lassen.
  • Der Entwurf -01 erwägt weitreichende Router-Schnittstellen, während sein Abschnitt zu Sicherheitsaspekten noch mit „TBD“ markiert ist. Das Dokument ist ein individueller Vorschlag, weder IETF-Standard noch Nachweis eines Produktivbetriebs.

Das Modell erhält eine andere Aufgabe

Das geläufige Bild von KI im Netzbetrieb platziert das Modell außerhalb des Netzes: Es wertet Telemetrie aus, fasst Störungen zusammen oder empfiehlt Konfigurationen, während bestehende Steuerungs- und Verwaltungssysteme die Geräte weiter betreiben. AI4AN fragt, was sich ändert, wenn ein LLM auch die Software erstellt, die diese Automatisierung ausführt.

Toerless Eckert und Alexander Clemm beschreiben ein Agentic Network DevOps Center, das einen Programmierauftrag entgegennimmt, interpretiert und mit einem LLM Automatisierungssoftware entwickelt. Diese würde als Autonomic Service Agent (ASA) auf einzelnen oder vielen Netzwerkgeräten laufen. Das Modell dient in erster Linie als Entwicklungswerkzeug; nach der Installation wird das Programm zum dauerhaft handelnden Akteur. Der Entwurf schließt direkte agentische LLM-Automatisierung dort nicht aus, wo sie machbar ist. Vorgeschlagen wird eine Softwareschicht zwischen Modellschlussfolgerung und Geräteaktion, kein Verbot direkter Nutzung.

Diese Trennung könnte es ermöglichen, Code vor der Installation zu prüfen, zu versionieren und zu testen. Der Entwurf nennt Netzwerksimulation, umfangreiche Tests und, sofern möglich, formale oder modellgestützte Validierung. Er legt jedoch weder einen Abdeckungsgrad noch ein Abnahmeverfahren oder Feldergebnisse fest. Das sind vorgeschlagene Verfahren, keine bereits belegten Garantien.

Am Gerät wird die Grenze konkret

Das Architekturdiagramm ordnet die Entwicklungsumgebung über einer Ausführungsebene auf den Geräten ein, neben den bestehenden Steuerungs- und Verwaltungsprozessen. Es verweist auf ANIMA-Bausteine wie das Autonomic Control Plane, die sichere Inbetriebnahme über BRSKI und die Koordination mit GRASP. Diese RFCs liefern technischen Kontext, machen AI4AN aber nicht zum verabschiedeten Standard.

Der Abschnitt zu Agent-Geräte-Schnittstellen zeigt die mögliche Tragweite. Die Umgebung könnte Router-CLI-Zugriff bis zur höchsten Berechtigungsstufe benötigen, das Dateisystem lesen, ändern, beschreiben und löschen, Management- oder Protokoll-Sockets ansprechen sowie Hardware- und Softwarediagnosen erreichen. Das sind im Entwurf erwogene Fähigkeiten. Er verlangt nicht, dass jede Implementierung alle diese Zugriffe öffnet, und belegt auch keinen laufenden Einsatz.

Im Entwurf -01 steht im Abschnitt „Security Considerations“ lediglich „TBD“. Das ist eine Lücke dieser Fassung, kein Beweis für eine grundsätzlich unsichere Architektur. Noch ungeklärt sind aber die Authentisierung erzeugter Programme, die Begrenzung ihrer Rechte, der Bezug zwischen Simulation und realem Netzzustand sowie das Zurückziehen eines fehlerhaften Agenten. Diese Fragen müssen spätere Fassungen und Implementierungen beantworten.

Eckerts Beitrag und der offene Architekturstreit

Toerless Eckert verfasst AI4AN gemeinsam mit Alexander Clemm und leitet die ANIMA-Arbeitsgruppe. Das Protokoll der ANIMA-Sitzung bei IETF 126 hält ihre Vorstellung und die Diskussion mehrerer Wege fest: ein LLM direkt in der autonomischen Regelschleife, ein Modell nur für begrenzte Parameteroptimierung oder ein Entwicklungs- und Bereitstellungsassistent, der deterministische ASAs erzeugt und prüft. Das Protokoll dokumentiert weder Konsens noch Übernahme des Entwurfs oder Genehmigung einer neuen Arbeitsgruppen-Charta.

Der Beitrag verschiebt die Frage von „Ist das Modell klug genug?“ zu „Welche Software läuft auf welchen Geräten und mit wessen Freigabe?“. Generierter Code kann wie anderer Code geprüft werden. Vertrauen muss dann aber die gesamte Kette abdecken: Eingaben, Artefakt, Tests, Signatur, gestaffelte Freigabe und Rücknahme.

Heng Lus Note 65 „Running-Code Primacy“ dient hier als redaktioneller Maßstab, nicht als Beleg für Aussagen über Eckert: Eine veröffentlichte Spezifikation ist weder lokale Validierung noch Implementierung, Übernahme oder beobachtetes Verhalten im laufenden Netz. Für AI4AN wären als Nächstes eine ausgearbeitete Sicherheitssektion, reproduzierbare Testumgebungen, eine klare Signatur- und Update-Kette, Gerätezugriffe mit minimalen Rechten sowie unabhängige Implementierungen oder Betreiberversuche aussagekräftig. Die Ausführungsgrenze ist erkennbar; ihre Garantien sind noch nicht festgelegt.

Quellen