Zusammenfassung

  • vn-compute aus RFC 9731 arbeitet vor der Instanziierung. Der RPC kann ein berechnetes VN und Verweise auf eine Connectivity Matrix liefern, erzeugt aber kein VN und reserviert keine Ressource.
  • Ein verfügbarer Pfad ist eine Aussage über den Informationsstand der Berechnung. Eine Reservierung ist eine Handlung der Stelle, die über die Ressource verfügen darf.
  • Belastbare Freigaben verbinden den Berechnungs-Snapshot mit späteren, getrennten Belegen für Konfiguration, Domain-Zulassung, installierte Tunnel, Betriebszustand, Verkehr und Kundenergebnis.

Um 10:04 Uhr fand die Berechnung einen Pfad. Um 10:07 Uhr zeigte die Freigabe noch immer grün. Um 10:09 Uhr verpflichtete eine andere Anforderung dieselbe knappe Kapazität.

Keine der beiden ersten Anzeigen war zwingend falsch. Falsch war die Annahme, Verfügbarkeit habe das Wettbewerbsfenster geschlossen.

RFC 9731 beschreibt vn-compute als eine Funktion vor der Instanziierung. Sie kann ein vollständiges virtuelles Netz zur Prüfung berechnen. Der Standard sagt zugleich ausdrücklich, dass diese Berechnung weder ein VN erzeugt noch Ressourcen im System reserviert.

Die Grenze liegt damit nicht zwischen einem guten und einem schlechten Algorithmus. Sie liegt zwischen Wissen und Verfügungsmacht.

Die Kundensicht ist eine bewusste Abstraktion

RFC 9731 definiert ein YANG-Modell für Virtual-Network-Operationen. ACTN dient als wichtigstes Beispiel: Der Customer Network Controller drückt Kundensicht und Bedarf aus, der Multi-Domain Service Coordinator koordiniert Informationen und Berechnung. Access Points beschreiben Kundenendpunkte; Virtual Network Access Points teilen einen AP für mehrere VNs und führen zur Provider-Kante.

Ein Type-1-VN kann als Satz abstrakter Edge-to-Edge-Links erscheinen. Ein Type-2-VN kann virtuelle Knoten, virtuelle Links und einen vorgesehenen Pfad zeigen. Der Kunde muss nicht jede interne Topologie und lokale Policy kennen.

Diese Abstraktion ist nützlich, weil sie Details auslässt. Gerade deshalb ist sie kein Ressourcenbuch. Ein sichtbarer Link besagt nicht, welche konkrete Kapazität welcher Domain bereits zugesagt wurde.

Auch die Grenze des Service Model ist relevant: Es setzt nicht voraus, wie ein Dienst tatsächlich entwickelt und geliefert wird. Anforderung und Ausführung bleiben verschiedene Tatsachen.

Die Berechnung ist präzise, aber vorläufig

vn-compute kann Constraints und Optimierungsziele auf VN- und Member-Ebene aufnehmen. Member-Werte dürfen breitere Werte überschreiben. Die Ausgabe kann auf eine abstrakte Single-Node-Topologie und für jedes Mitglied auf eine connectivity-matrix-id mit Pfadeigenschaften verweisen.

Damit lässt sich wesentlich mehr prüfen als mit einem bloßen „path found“. Der Aufrufer kann Mitglieder, Regeln und Ergebnis strukturiert miteinander verbinden.

Trotzdem bleibt die Ausgabe ein Resultat über einen Informationsstand. Das MDSC rechnet mit lokal verfügbaren Angaben oder mit Informationen aus der Koordination mit dem CNC. Weder wird ein Live-VN erzeugt noch wechselt eine Ressource den Verfügungsberechtigten.

„Verfügbar“ ist zeitgebunden

Zu den möglichen Berechnungsfehlern gehören ein noch nicht bereites MDSC, ein nicht erreichbares abhängiges CNC, keine verfügbare Ressource, kein gefundener Pfad und ein unbekannter Access Point.

Aus dem Ausbleiben von „no available resource“ folgt nicht, dass Kapazität gesichert ist. Es folgt nur, dass die verwendete Sicht unter den verwendeten Bedingungen eine Lösung hergab.

Vor dem Commit kann ein anderer Antrag gewinnen. Eine lokale Quota kann erreicht werden, ein Wartungszustand beginnen, eine Policy geändert oder ein abstrakter Link neu abgebildet werden. Die spätere Zulassung darf zu Recht anders ausfallen als die frühere Berechnung.

Verfügbarkeit ist eine Eigenschaft des Snapshots. Reservierung ist ein autorisierter Zustandswechsel. Beide brauchen unterschiedliche Autoren und Zeitpunkte.

Ein erfolgreicher RPC trägt einen kleinen Beleg

Eine erfolgreiche Antwort kann belegen, dass die Anfrage angenommen wurde, die Berechnung nicht mit einem definierten Fehler endete und zu einer bestimmten Zeit bestimmte Mitglieder, Topologie- und Matrixverweise unter bestimmten Constraints zurückgab.

Sie belegt allein nicht, dass der Antragsteller das Live-VN anlegen durfte. Sie zeigt keinen Commit in den vorgesehenen Datastore, keine Zulassung aller Domains und keine installierten Tunnel oder LSPs. Ebenso wenig beweist sie Konvergenz, Verkehr, Latenz, Schutzverhalten oder Abnahme durch den Kunden.

Die enge Semantik ist keine Schwäche. Der Berechnungsbeleg bleibt glaubwürdig, wenn er nicht für spätere Ereignisse sprechen muss.

Die Connectivity Matrix ist kein Kapazitätskonto

Die berechnete Ausgabe verweist auf Matrixeinträge in einer abstrakten Topologie. Sie können gültige Switching-Kombinationen und mögliche TE-Pfadeigenschaften eines abstrakten Knotens ausdrücken.

Der Verweis ermöglicht eine kontrollierte Prüfung, ohne den ganzen Underlay offenzulegen. Er teilt aber keine Bandbreite zu und belegt weder die Konfiguration jedes Segments noch Aufbau und Forwarding eines LSP.

Wird die Matrix-ID in ein Change-Ticket kopiert und dort „provisioned“ genannt, hat sich nur die Beschriftung geändert. Für die Existenzbehauptung fehlen weiterhin reale Objekt-IDs, Installationsausgänge und Betriebsbeobachtung.

Ressourcengewalt bleibt verteilt

Ein MDSC kann eine Multi-Domain-Berechnung koordinieren, ohne über sämtliche Kapazität verfügen zu dürfen. Jede Domain kann eigene Admission Policy, Wartung, Quota, Schutzvorgaben und konkurrierende Nachfrage haben.

Kunden-Constraints prägen die Lösung, ersetzen aber keine lokale Genehmigung. Ein durchgängiger abstrakter Pfad wird erst dann zum Commitment, wenn alle notwendigen Eigentümer ihre jeweiligen Teile akzeptieren.

Der Berechnungsdienst belegt Eingabe, Versionen und Resultat. Die Konfigurationsinstanz belegt die Absicht. Ressourcenhalter belegen Zulassung oder Ablehnung. Provisioning belegt konkrete Tunnel und LSPs. Betrieb belegt Konvergenz; die Servicekante belegt Verkehr. Automatisierung verbindet diese Autoren, sie vereinigt ihre Befugnisse nicht.

Das Wettbewerbsfenster braucht Ablaufregeln

Eine richtige Berechnung altert ab dem Moment ihrer Erstellung. Topologie, Policy, Ressourcensicht, Access Point oder abhängiger Controller können sich ändern, während ein Freigabeprozess wartet.

Der Nachweis sollte deshalb Constraints, Member, Versionen von abstrakter Topologie und Matrix, Policy-Revision, Zeit der Ressourcensicht, beteiligte Controller und ein Ablaufkriterium binden. Eine relevante Änderung löst Neuberechnung oder erneute Prüfung aus.

Ohne diese Hülle ist nicht erkennbar, ob ein Ergebnis frisch berechnet oder nur wieder abgespielt wurde. Das Dashboard zeigt dieselbe Linie, obwohl die zugrunde liegende Option nicht mehr existiert.

Konfiguration und Betrieb bleiben verschiedene Ebenen

Das Modell folgt NMDA und bringt Konfiguration und Operational State in dieselbe Baumstruktur. Das erleichtert Navigation, hebt den Unterschied zwischen Absicht und Beobachtung aber nicht auf.

Ein VN-Member kann konfiguriert sein und operational weiterhin down melden. Während der Konvergenz kann ein Zustand noch eine ältere Konfiguration widerspiegeln. Eine kombinierte Antwort kann Blätter mit unterschiedlichen Autoren und Zeitpunkten enthalten.

Der Beleg braucht deshalb Datastore, Zeit, Controller und Modellrevision. Nähe im Schema ist keine Kausalität.

Berechnungsfehler sind keine Lifecycle-Taxonomie

Die definierten Fehlergründe erklären den Computation-Schritt. Sie umfassen nicht alle Fehler späterer Reservierung, Instanziierung und Dienstbeobachtung.

Eine Reservierung kann nach einer gültigen Berechnung scheitern. Provisioning kann nur in einigen Domains erfolgreich sein. Operational State kann nicht konvergieren. Verkehr kann einen abstrakt passenden Pfad nutzen und das Kundenbedürfnis dennoch verfehlen.

Jede Stufe benötigt eigene positive und negative Belege. Ein aggregierter Erfolg verwischt partielle Ergebnisse und macht aus der ersten grünen Anzeige eine falsche Endaussage.

Compute ist nicht Create

Die Sicherheitsbetrachtung setzt geschützte NETCONF- oder RESTCONF-Verbindungen und NACM für Zugriffskontrolle voraus. Konfigurations- und Betriebsdaten können sensibel sein; auch vn-compute kann VN-Informationen offenlegen.

Die Berechtigung zur Berechnung ist daher selbst schützenswert. Sie kann Topologie, Endpunkte, Policy und potenzielle Kapazität sichtbar machen. Daraus folgt aber nicht, dass dieselbe Identität konfigurieren oder reservieren darf.

Read, compute, configure, reserve und delete lassen sich als getrennte Fähigkeiten behandeln. Das Planungssystem erhält Compute-Rechte, die Live-Änderung bleibt einer gesondert freigegebenen Instanz vorbehalten.

Verwerfen ist noch kein Rollback

Da die Vorberechnung weder VN noch Reservierung anlegt, lässt sich ihr Ergebnis ohne Produktionsänderung verwerfen und bei Bedarf neu erstellen.

Nach dem tatsächlichen Commitment ist Umkehr aufwendiger. Tunnel müssen entfernt, Kapazität freigegeben, Policies zurückgesetzt, Domains koordiniert und laufender Verkehr geschützt werden. Dann ist realer Zustand entstanden.

Beide Vorgänge „Rollback“ zu nennen, versteckt den Punkt, an dem Kosten und Risiko beginnen. Vor dem Commit wird ein Vorschlag aufgegeben; danach wird ein laufendes System verändert.

Eine Belegkette schließt das Fenster

Zuerst werden akzeptierte Berechnungsanfrage und Informations-Snapshot gespeichert. Dann folgen Ergebnis, Member, Matrixverweise und Fehler. Danach kommt eine eigenständige Konfigurationsentscheidung mit Genehmiger. Jede erforderliche Domain liefert ihre Admission. Provisioning hält tatsächliche Tunnel- oder LSP-IDs fest. Betrieb beobachtet Konvergenz, die Kundenkante den Verkehr. Am Ende steht Kundenabnahme oder eine dokumentierte Lücke.

Der Übergang kann schnell und automatisch sein. Entscheidend ist, dass jede Stufe einen eigenen Beleg ausstellt und ein abgelaufener Vorgänger keine spätere Autorität vortäuscht.

RFC 9731 liefert die erste klare Regel: Der berechnete Pfad ist noch keine reservierte Ressource.

Quellen