Zusammenfassung

  • draft-ietf-ccamp-fgotn-yang-02 nennt einen bidirektionalen fgODUflex-Resize erst nach Abschluss beider Richtungen erfolgreich, lässt den Endstatus zum MDSC aber allein vom Quell-Controller melden.
  • lsp-bandwidth-modified-ok belegt weder sämtliche angewandten Slots noch konsistente Schutzpfade, fehlende Zwangseingriffe oder ungestörten Kundenverkehr.
  • Der Abschluss braucht Teilnehmerbelege, generationsgebundene Ressourcenkontrolle, Operational-State-Readback und gemessene Service-Postconditions.

Der MDSC fordert zusätzliche Kapazität an. Controller 1 ändert die Hinrichtung. Der entfernte Knoten stößt die Rückrichtung an. Controller 3 meldet deren Beginn. Schließlich sendet Controller 1 lsp-bandwidth-modified-ok.

Die Oberfläche zeigt Erfolg. Die Nachricht sagt aber zunächst nur, dass der Quell-Controller seinen Ablauf für abgeschlossen hält.

Der Entwurf selbst verteilt die Beweislast. Beide Richtungen müssen beendet sein. Alle Domain-Controller melden Topologie- und Tunneländerungen. Bei 1+1-Schutz nehmen Arbeits- und Schutzpfad teil. Scheitert eine Richtung, darf ein erzwungener Abgleich folgen, der den Dienst beeinträchtigen kann.

Eine letzte Meldung komprimiert also viele Beobachtungen. Sie ersetzt sie nicht.

Revision 02 erschien am 30. September 2026 als aktiver CCAMP-WG-Entwurf. Der Datatracker nennt weder vorgesehenen RFC-Status noch verantwortlichen AD oder IESG-Stand. Manageability, Security und IANA enthalten Platzhalter. Das Dokument ist kein RFC, kein Interoperabilitätsnachweis und keine Produkteigenschaft.

Ein modellierter Slot ist noch keine gelieferte Kapazität

fgOTN soll kleine Clientsignale, auch unter 1 Gbit/s, effizient in größere OTN-Serverkapazität einbetten. Das Modell ergänzt fgODUflex, eine Bandbreite von 1 bis 119 feinen Tributary Slots und fgts-numbers für primäre, rückwärtige, sekundäre und tatsächlich beobachtete Routen.

Damit kann ein Controller Ressourcen präzise benennen. Ein Konfigurationswert beweist aber keine physische Exklusivität. Topologieverfügbarkeit, angewandter Zustand und Kundendienst sind getrennte Ebenen.

Der Datastore kann 30 Slots zeigen, während der Schutzpfad bei 20 bleibt. Zwei Domains können auf unterschiedlichen Topologiegenerationen denselben Bereich reservieren. Ein Gerät kann die Konfiguration annehmen, bevor Hardware sie vollständig umsetzt. Der Verkehr kann trotz passender Werte Fehler zeigen.

Der belastbare Invariant verbindet Service, Server-ODU, Link, Generation, Slotmenge, Konfliktprüfung, Readback und Verkehrsmessung. Die Zahl allein besitzt diesen Kontext nicht.

RFC 8342 trennt beabsichtigten, angewandten und operativen Zustand. Selbst Operational State ist noch keine Messung dessen, was der Kunde erlebt.

Zwei Richtungen haben zwei Fehlergeschichten

Der Client übermittelt fgODUflex-ID und Ziel an den Quell-Controller. Ressourcen werden vor der Aktion reserviert oder markiert. Hinrichtung ändert sich Knoten für Knoten; am Ziel startet die Rückrichtung. Erfolg setzt beide voraus.

Zusätzlich müssen beide Ereignisse zur selben Transaktion gehören. Eine verspätete Meldung eines alten Versuchs darf keinen neuen schließen. Eine abgelaufene Reservierung wird nicht durch gleiche Werte wieder gültig. Nach einem Neustart wiederverwendete lokale IDs dürfen Historie nicht umdeuten.

Jede Richtung braucht Request-Hash, Transaktionsgeneration, Policy-Version, Ziel, Topologie, Reservierungen, Domains, angewandtes Ergebnis und Readback. Der Gesamtbeleg verbindet die Zeitlinien, ohne ihre Eigenständigkeit zu löschen.

Der Berichterstatter ist nicht jeder Zeuge

Anhang A lässt Controller 1 Start und Ende melden, Controller 3 den Rückstart und alle Domains ihre Ressourcendeltas. Es gibt ein Entscheidungsbuch und ein Evidenzbuch.

Im ersten steht, wer anforderte, zuließ und abschloss. Im zweiten steht, was jede Domain in welcher Richtung und Generation sah. Wer nur die letzte Nachricht speichert, verliert nach Failover oder Streit den unabhängigen Prüfpfad.

Der Abschluss sollte Transaktion, Ziel, erforderliche Teilnehmer, Digest der Belege, Policy und Ausnahmen referenzieren. Beobachtungen bleiben ihren Urhebern zugeordnet. Der Quell-Controller aggregiert, statt fremde Wahrnehmung zu übernehmen.

Das verhindert Lock-in. Liegt die wahre Geschichte nur im proprietären Log eines Orchestrators, löscht ein Produktwechsel das operative Gedächtnis. Fortbestehen muss das prüfbare Ledger, nicht der aktuelle Gatekeeper.

Schutz vervierfacht die Abschlussfläche

Bei 1+1 arbeiten Arbeits- und Schutzpfad mit. Zusammen mit Hin- und Rückrichtung entstehen vier Flächen: hin/working, zurück/working, hin/protection, zurück/protection.

Der aktive Pfad kann die neue Bandbreite tragen, während der Ersatzpfad alt bleibt. Der Mangel zeigt sich erst beim nächsten Ausfall. Schutz ist daher keine Nebeninformation, sondern ein heutiger Nachweis für eine künftige Zusage.

Die Policy muss festlegen, ob unvollständiger Schutz Erfolg verhindert, einen befristeten Degraded-Zustand erzeugt oder eine genehmigte Ausnahme braucht. Ein grüner Arbeitsweg darf ihn nicht verdecken. Konfigurierte Labels und tatsächlich umschaltbare Serverressourcen müssen getrennt gelesen werden.

Erzwungene Konsistenz kann den Dienst treffen

Wenn eine Richtung erfolgreich ist und die andere scheitert, erlaubt der Entwurf einen erzwungenen Abgleich und warnt vor Beeinträchtigung. Damit wird Fehlerbehandlung zur Autoritätsfrage.

Warten, erneut versuchen, zurückrollen oder erzwingen verteilen Risiken unterschiedlich. Erzwungene Symmetrie säubert den Kontrollzustand, kann aber Pakete unterbrechen. Ein Rollback kann zusätzlichen Wandel verursachen. Warten hält asymmetrische Ressourcen offen.

Die Vorliebe für Konsistenz ist keine automatische Erlaubnis, Kunden zu treffen. Zwang braucht benannten Entscheider, Grund, Alternativen, Wartungskontext, Umfang, Rückrollpunkt und Nachmessung. Trat eine Beeinträchtigung auf, darf das Ergebnis „nach Reparatur konsistent“ heißen, nicht uneingeschränkt „hitless“.

Der Controller darf handeln. Das laufende Netz bestimmt die Bedeutung des Resultats.

Schema-Validität ist keine Transaktionsvollständigkeit

Die Datatracker-Prüfung meldet null Fehler und Warnungen für die Module. Das ist ein Schema-Nachweis, kein End-to-End-Test.

Sie simuliert keinen Absturz zwischen den Richtungen, keine verspätete Protection, keine doppelten Events und kein Gerät, das schreibt, aber nicht schaltet. Revision 02 liefert Modelle und ein Fünf-Schritte-Szenario, jedoch noch keine verpflichtende globale Transaktions-ID, Quorum-, Timeout-, Idempotenz-, Reihenfolge-, Audit-, Rollback- oder Servicemessregel.

Zwei Implementierungen können dieselben YANG-Blätter zeigen und zu verschiedenen Zeitpunkten „fertig“ sagen. Tests müssen Schema, RPC, Datastore, Gerät, Multi-Domain-Konvergenz, Schutz und Verkehr getrennt prüfen.

Der erforderliche Abschlussbeleg

Vor dem Write werden Service, Ist- und Zielbandbreite, Servergrenze, Topologiegeneration, Pfade, Policy, Autorisierung und Wartungskontext fixiert. Bei der Reservierung liefern Domains Slots mit Link, Schicht, Verfügbarkeitsgeneration, Konfliktprüfung und Ablauf.

In der Ausführung bleiben Zeitlinien je Richtung und Rolle getrennt. Start, angewandte Konfiguration, Operational Readback, Delta und Ausnahme werden transaktionsgebunden gespeichert.

Beim Abschluss prüft der MDSC Teilnehmer, Zielparität, Ressourcenerhaltung, Schutz und Zwangsaktionen. Die Quellmeldung verweist auf den Belegsatz.

Danach folgen Verlust, Fehler, Latenz, Durchsatz, Alarme und Reversion in einem definierten Vorher-Nachher-Fenster. Erst diese Ebene kann Unterbrechungsfreiheit belegen.