Zusammenfassung

  • Der Entwurf draft-ietf-teas-actn-poi-applicability-20 befindet sich bis zum 23. September 2026 im IESG Last Call und zielt auf einen informativen RFC. Zwei Bewertungen „Not ready“ sind Stellungnahmen von Gutachtern, kein Beschluss der IESG.
  • Der Sicherheitsgutachter fordert eine Analyse von Werten und Vertrauensgrenzen. Der Betriebsgutachter fragt, wie MDSC und PNC nach Neustarts, verlorenen Meldungen, Failover oder nur teilweise ausgeführten Änderungen wieder zu einem konsistenten Zustand gelangen.
  • Vor einer Delegation realer Änderungen sollten Betreiber Berechtigung, Alter der Daten, Identität laufender Vorgänge, Ausgleich nach Teilerfolg und die Dienstwirkung gemeinsam prüfen. Dieser Prüfrahmen ist redaktionelle Analyse, keine zusätzliche Normvorgabe.

Wenn der zweite Controller schweigt

Ein MDSC hat die Paketdomäne zu einer Änderung veranlasst, die optische Domäne antwortet nicht mehr. Die erste Bestätigung beweist weder eine vollständig eingerichtete Verbindung noch, dass eine Wiederholung gefahrlos ist. Dieses Beispiel ist ein gedanklicher Test, kein dokumentierter Netzausfall. Es zeigt, weshalb die größte Betriebsfrage zwischen den Kästchen eines Architekturbildes liegt.

Die 20. Fassung des ACTN/POI-Entwurfs beschreibt, wie ein Multi-Domain Service Coordinator (MDSC) Provisioning Network Controllers (PNCs) für Paket- und optische Netze mit bestehenden Protokollen und YANG-Modellen koordiniert. Der IESG Last Call begann am 9. September und endet am 23. September. Vorgesehen ist ein informatives Dokument. Am 21. September war es weiterhin ein Internet-Draft, weder gebilligt noch als RFC veröffentlicht. Sicherheits- und Betriebskapitel sind bereits vorhanden; die Gutachten stellen deren Aussagekraft für diese Architektur infrage.

Das Ergebnis der Begutachtung ist nicht einheitlich. Yaron Sheffer für das Security Directorate schloss seine Prüfung am 18. September mit „Not ready“ ab; Nick Buraglio für das Operations Directorate folgte am 19. September mit demselben Kennzeichen. Buraglio nennt im Überblick einige Einwände geringfügig, behandelt die unzureichenden Betriebsbetrachtungen im Detail aber als Hauptproblem. Zheng Zhangs Routing-Gutachten lautet „Ready“ und bittet überwiegend um kleinere Erläuterungen. Ein Directorate-Eintrag entscheidet nicht über Annahme oder Ablehnung durch die IESG.

Berechtigter Absender, fraglicher Inhalt

Sheffer hält fest, dass Kapitel 7 abgesicherte Schnittstellen und LLDP behandelt. Für ein System mit mehreren Verwaltungsdomänen, Herstellern und Vertrauensverhältnissen verlangt er zusätzlich eine knappe Bedrohungsanalyse: Was sind die schutzwürdigen Werte und Grenzen, und was geschieht bei kompromittierten oder böswilligen Controllern, falschen oder veralteten Topologie- und Ressourcenmeldungen, unbefugten Eingriffen zwischen Schichten, Offenlegung, Ressourcenerschöpfung und widersprüchlichem Paket- und Optikzustand? Er verlangt keine vollständige Taxonomie.

Zugleich sagt er, dass er die umfangreichen technischen Einzelheiten nicht umfassend bewerten könne. Daraus lässt sich kein nachgewiesener Angriff ableiten.

Der ACTN-Rahmen in RFC 8453 erlaubt nach Richtlinien abstrahierte Sichten zwischen PNC und MDSC. TLS und Zugriffsregeln können den Kommunikationsweg und die handelnde Identität schützen. Sie können für sich allein nicht belegen, dass eine Ressource im Moment des Eingriffs noch verfügbar ist, dass die Berechtigung gerade diesen schichtübergreifenden Auftrag umfasst oder dass ein neu gestarteter PNC frühere Zusagen noch kennt. Die Kritik zielt also auf das Betriebsvertrauen hinter der gesicherten Leitung.

Zwei Datenbanken, keine gemeinsame Gegenwart

Buraglio richtet den Blick auf die Zustandsmeldungen, aus denen der MDSC sein Bild von Topologie und Diensten zusammensetzt. Geht eine Benachrichtigung verloren oder startet ein PNC neu, können Koordinator und Domäne verschiedene Ansichten für aktuell halten. Wie wird diese Abweichung entdeckt, wie wird der Stand rekonstruiert und was geschieht mit offenen Aufträgen während PNC-Neustart oder MDSC-Failover? Welche Wirkung hat die Nichtverfügbarkeit des MDSC auf bereits eingerichtete Dienste? Ein normaler Pfadberechnungstest beantwortet diese Fragen nicht.

Der Gutachter vermisst außerdem Hinweise zu Zeitbedarf, Timeouts und Wiederholungen bei den aufeinanderfolgenden Schritten zwischen MDSC, Paket-PNC und optischem PNC. Er fragt ausdrücklich, was geschieht, wenn eine Domäne erfolgreich umkonfiguriert wird und die andere scheitert. Daraus ergibt sich für die Erprobung: Ein neuer Versuch muss dem alten Vorgang zugeordnet werden, und ein Ausgleich darf nicht über den tatsächlich festgelegten Zustand einer Domäne hinweggehen. Das ist eine betriebliche Folgerung dieses Artikels, kein im Entwurf vorgeschriebener Rollback-Mechanismus und keine Beschreibung eines Vorfalls.

Weitere Punkte betreffen die schrittweise Einführung in Bestandsnetzen, Fähigkeiten eines Teams für beide Schichten, Grenzen der Skalierbarkeit, die Dauerhaftigkeit eines Binding SID nach Neustart, die Wiederherstellung von Benachrichtigungsabonnements und die Protokollierung von Änderungen. Nicht alles muss in einem informativen RFC bis zum letzten Produktdetail normiert werden. Der Betreiber braucht jedoch vor der Beauftragung eine erkennbare Grenze zwischen gemeinsamem Modell, herstellerspezifischer Umsetzung und eigenem Verfahren.

Der Abnahmetest gehört an die Übergabe

Für jeden Vorgang sollten mindestens fünf Fragen mit demselben Vorgang verknüpft beantwortbar sein: Wer durfte handeln? Welche Version der Ressourcenlage lag jeder Entscheidung zugrunde? Woran erkennt man den offenen Auftrag nach einem Failover wieder? Welche PNCs haben wirklich bestätigt oder abgelehnt? Was zeigte anschließend der Dienst? Ein Test lässt absichtlich eine Meldung ausfallen, startet einen PNC mitten im Auftrag neu, wechselt den MDSC zwischen zwei Antworten und lässt nur eine Schicht erfolgreich sein. Ein ehrliches „Zustand unbekannt, neue Eingriffe ausgesetzt“ ist dabei wertvoller als ein scheinbar grünes Dashboard.

Dieser Nachweis ist ein Vorschlag der Redaktion, kein neues IETF-Datenschema. Er unterscheidet den aktuellen Anlass von einer älteren Betrachtung abstrakter Topologie als Richtliniensicht und nicht als Inventar. Jetzt geht es um Handlungsfähigkeit, wenn Autorität über mehrere Controller verteilt wurde. Last Call kann noch zu Antworten, Revisionen oder Zustimmung führen. Die Quellen belegen weder eine formelle Ablehnung noch einen Angriff oder Dienstunterbruch in einer realen Installation.

Quellen

ACTN/POI-Entwurf und Status; Sicherheitsgutachten; Betriebsgutachten; Routing-Gutachten; ACTN-Rahmen RFC 8453.