Zusammenfassung

  • RFC 9835 hinterlegt beim Netz-AC die Referenz des service-seitig angebotenen AC. Diese Korrelation macht einen Auftrag nachvollziehbar, beweist aber keinen Bearer, keine Weiterleitung und keine Lieferung.
  • Ein Netz-AC-Name gilt innerhalb eines Knotens. Vererbte Profile, lokale Überschreibungen, Eltern-Kind-Abhängigkeiten sowie administrativer und operativer Zustand bilden erst gemeinsam den wirksamen Stand.
  • Der Beleg muss bis zum richtigen Ziel, zur beobachteten Konfiguration, zum begrenzten OAM, zum Gesamtdienst und zum nutzbaren Kundenverkehr reichen.

Zwei grüne Systeme, ein unerreichbarer Standort

Ein Unternehmen bestellt Konnektivität für eine Niederlassung. Das Portal vergibt eine Referenz. Der Orchestrator wählt einen Provider Edge und legt einen Attachment Circuit an. Weil Auftrag und Inventar denselben Schlüssel zeigen, wirkt der Prozess abgeschlossen. Dennoch kann der physische oder logische Bearer ausfallen, die VLAN-Zuordnung falsch sein oder ein anderes VPN-Ende fehlen.

Die Referenz beantwortet die Identitätsfrage: Welches Netzobjekt soll welchen Auftrag umsetzen? Sie beantwortet nicht die Wirkungsfrage.

RFC 9835 und sein RFC-Editor-Datensatz beschreiben ietf-ac-ntw, ein Netzmodell für Attachment Circuits. Es kann ACs vor oder während der Servicebereitstellung provisionieren und die service-seitige Referenz am Netzobjekt erhalten.

Auftrag, Referenz, wirksame Netzkonfiguration, beobachteter Zustand und Kundenergebnis bleiben verschiedene Belege. Das ist keine unnötige Bürokratie, sondern die Grenze zwischen Zuordnung und Ausführung.

Bearer und AC haben unterschiedliche Fehlerflächen

RFC 9833 nennt den physischen oder logischen Link zwischen Kundenpunkt und Providernetz Bearer. Der AC ist die darauf provisionierte Einrichtung für den Datenaustausch. Ein Bearer kann mehrere ACs tragen; ein AC kann mehrere Peer-SAPs anbinden; ein SAP kann mehrere ACs terminieren.

Ein Bearer-Defekt kann viele ACs gemeinsam treffen. Eine fehlerhafte AC-Konfiguration kann bei gesundem Bearer bestehen. Die Bearer-Referenz zeigt, wo ein Dienst gebunden werden soll, nicht dass er korrekt gebunden wurde.

RFC 9834 stellt Bearer und AC als kundenseitige Services bereit. RFC 9835 beschreibt die Netzseite. RFC 9836 verbindet diese Referenzen mit L2VPN- und L3VPN-Service- und Netzmodellen. Die Architektur standardisiert den Übergang, nicht die Behauptung, alle Ebenen seien gleichzeitig erfolgreich.

Ein belastbarer Datensatz enthält Service-Referenz, Netz, Knoten, lokalen AC-Namen, SAP, Bearer und Gültigkeitsepoche. Ein global wirkender Anzeigename kann sonst gleichnamige ACs oder eine Migration falsch zusammenführen.

svc-ref ist ein Join, kein Urteil

RFC 9835 nutzt die vom Servicemodell veröffentlichte Referenz, um den Serviceauftrag mit dem tatsächlich im Netz provisionierten AC zu korrelieren. Der AC-Name ist jedoch nur innerhalb eines Knotens eindeutig. Ob Service- und Netzebene dieselbe Namenskonvention benutzen, ist deploymentspezifisch.

Mehrere Knoten dürfen ac-17 besitzen. Eine stabile Kundenreferenz darf nach einer Migration eine neue Implementierung bezeichnen. Der Nachweis braucht deshalb das ganze Tupel mit verantwortlichem Orchestrator und Epoche.

RFC 8969 trennt Customer-Service-, Netz- und Gerätemodelle. Ihre Übersetzung ist eine operative Entscheidung. Gemeinsame Schemata verringern Missverständnisse, beweisen aber nicht die physische Ausführung.

Die wirksame Konfiguration ist abgeleitet

RFC 9835 erlaubt netzweite Profile, deren Werte ein AC erbt. Verfeinert der AC denselben Datenknoten lokal, gewinnt der lokale Wert. Für die Rekonstruktion braucht man Profilversion, geerbte Werte, lokale Ausnahmen, Herkunft jedes Endwerts und einen Fingerabdruck der an das Ziel übermittelten Konfiguration.

Nur den Profilnamen zu speichern, verbirgt Ausnahmen. Nur die Ausnahme zu speichern, verbirgt die Grundlage. Eine spätere Profiländerung darf den historischen Zustand nicht rückwirkend umdeuten.

RFC 9836 gibt referenzierten AC-Daten Vorrang vor überlappenden Inline-Angaben eines VPN-Zugangs. Das löst einen Konflikt der Absicht. Es beweist keine atomare Anwendung, keine einheitliche Geräteinterpretation und keinen erfolgreichen Rollback.

RFC 8342 trennt in NMDA beabsichtigte Konfiguration und operativen Zustand. RFC 8345 liefert das von RFC 9835 erweiterte Netzgrundmodell. Die entscheidende Frage lautet nicht „existiert das Objekt?“, sondern „was war beabsichtigt, was wurde wirksam, was wird beobachtet?“

Das Löschen des Elternobjekts ist eine Kaskadenentscheidung

Ein Parent AC kann gemeinsame Eigenschaften für mehrere Peer-SAPs tragen; Child ACs halten spezifische Angaben und erben vom Elternobjekt. Wird der Parent AC gelöscht, müssen laut RFC 9835 alle Child ACs gelöscht werden.

Damit entstehen keine logischen Waisen. Gleichzeitig wächst der Wirkungsradius eines einzelnen Befehls. Das Schema beweist nicht, dass der Controller die richtigen Kinder ermittelt, Gerätezustand geordnet entfernt, fremde Services schützt, Abrechnung anpasst oder Rückkehr ermöglicht.

Vorher sollte ein Impact-Beleg Parent, Kinder, SAPs, Services, Bearer, wirksame Profile und Betriebszustände einfrieren. Nachher sind Modell, Gerätezustand und Kundentest abzugleichen. Eine gelöschte Datenzeile beweist keine sichere Verkehrseinstellung.

Administrativ und operativ müssen widersprechen dürfen

RFC 9835 hält administrativen und operativen Status getrennt; eine Abweichung kann eine Anomalie auslösen. RFC 9833 kennt etwa „wartet auf Validierung“, „wartet auf Verarbeitung“, administrativ verboten und abgelehnt. Das sind Workflow-Aussagen, keine Paketbeobachtungen.

Ein genehmigter Auftrag kann warten. Ein konfigurierter AC kann down sein. Ein Interface kann up sein und den falschen VLAN führen. Ein lokaler AC kann gesund sein, während der Gesamtdienst ausfällt.

RFC 9408 definiert den SAP als providerseitigen Referenzpunkt. Der dort beobachtete Servicezustand ist nicht der netzweite Zustand eines Dienstes über mehrere SAPs. RFC 9181, RFC 9182 und RFC 9291 liefern VPN-Typen und Netzmodelle; RFC 9543 erweitert den Kontext auf Network Slices. Kein lokales Grün darf für alle sprechen.

Die Belegkette trennt Anfrage, Annahme und Referenz; Mapping auf Netz/Knoten/SAP/AC; Vererbungsauflösung; Übermittlung an Ziele; operativen Zustand; begrenztes OAM; Ende-zu-Ende-Service; Kundenverkehr oder Applikations-Canary. Das müssen keine neun Datenbanken sein. Semantisch darf jedoch kein unterer Beleg die Autorität des nächsten annehmen.

Die Quellen belegen keine namentliche Implementierung, Produktkonformität, Störung, Verbreitung, Einsparung oder SLA-Wirkung. Die vorgeschlagene Belegpraxis ist operative Analyse, keine zusätzliche IETF-Vorschrift.

Lesezugriff ist ebenfalls Macht

RFC 9835 warnt, dass unbefugtes Lesen Kundenidentitäten in peer-sap-id offenlegen kann. Schreibbare Teilbäume können Routing, Filter, Verschlüsselung, Schlüssel und Servicebindungen verändern. Wer den Join zwischen Service und AC schreibt, bewegt mehr als Metadaten.

Kommerzielle Absicht, Netztranslation, Geräteschreibzugriff und Beobachtung sollten getrennte Rechte besitzen. Das Audit braucht authentifizierten Akteur, Scope, Altwert, Neuwert und Resultat. Ein erfolgreicher API-Aufruf ersetzt weder Mandat noch Lieferung.

Der dauerhafte Nutzen von RFC 9835 ist eine überprüfbare Naht zwischen Versprechen und Ausführung. Führt die Referenz weiter zu unabhängiger Beobachtung und Kundenergebnis, wird Automation zurechenbar. Schließt sie den Vorgang allein, automatisiert sie nur den Schein der Erfüllung.

Quellen