Zusammenfassung

  • RFC 9833–9836 modellieren Träger, kundenorientierten Attachment-Circuit-Service, Netz-AC des Providers und die Verweise zu L2- oder L3-VPNs getrennt.
  • Ein genehmigter und validierter Auftrag kann awaiting-processing bleiben. Auch die Namen von Service- und Netz-AC dürfen verschieden sein; Annahme oder Namensgleichheit beweisen keine Realisierung.
  • Erst Zuordnung, PE/SAP-Auswahl, VPN-Bindung, beabsichtigte und angewandte Konfiguration, Betriebszustand, OAM und Verkehr bilden die weitere Beweiskette.

Im Bestellsystem existierte der Anschluss. Im Netz des Providers existierte das Objekt, das ihn tragen sollte, noch nicht.

Dieser Abstand beweist für sich genommen weder Täuschung noch Störung. Er ist in RFC 9833, RFC 9834, RFC 9835 und RFC 9836 beabsichtigt. Die vier im September 2025 veröffentlichten Standards-Track-Dokumente verteilen Bestellung und Umsetzung auf verbundene YANG-Modelle. So kann der Status einer Schicht nicht unbemerkt zur Wahrheit einer anderen werden.

Die Infoseiten zu RFC 9833, RFC 9834, RFC 9835 und RFC 9836 belegen IETF-Konsens und IESG-Freigabe. Sie belegen keinen Einsatz bei einem Provider, keine Geräteumsetzung und keinen übertragenen Frame. Standardisierung und Betrieb sind getrennte Quittungen.

Ein Träger ist nicht der Attachment Circuit

Der Bearer ist die zugrunde liegende drahtgebundene oder drahtlose Verbindung. Der AC ist die darüber eingerichtete Anbindung, die Datenaustausch zwischen Kundenabschluss und Providernetz erlaubt. Ein Bearer kann mehrere ACs tragen; ein AC kann mehrere Kundengeräte oder Peer-SAPs betreffen; ein Kundengerät kann mehrere ACs terminieren.

Darum belegt ein verfügbarer Bearer nicht den richtigen aktiven Kundendienst. Die Kündigung eines Dienstes verleiht auch keine Befugnis, den gemeinsamen Bearer oder Geschwisterdienste zu entfernen. Eine einzige grüne Anzeige verwischt genau diese Reichweite.

RFC 9834 erlaubt dem Provider, eine Bearer-Referenz auszugeben, die der Kunde abruft und in einem späteren AC-Auftrag verwendet. Kundenkennungen kann der Provider annehmen oder ablehnen. Ein AC-Bezeichner ist nur innerhalb der Providerdomäne eindeutig. Aussteller, Geltungsbereich und aktuelles Ziel gehören deshalb zum Beleg.

Das Kundenmodell kennt die Werkstatt nicht

RFC 8309 beschreibt ein Customer-Service-Modell als Sicht auf den bestellten oder erlebten Dienst, nicht auf dessen interne technische Umsetzung. RFC 9834 verbirgt PE, SAP, Interface, Topologie und Technologie bewusst.

Die Abstraktion macht einen gemeinsamen Auftrag über unterschiedliche Netze hinweg tragbar. Sie verhindert zugleich, dass das Kundenobjekt als Beweis für die verborgene PE-Zuordnung dient. Seine Quittung umfasst authentifizierten Auftraggeber, Berechtigung, Bearer- oder Peer-SAP-Referenz, Service-AC-ID, Parameter, Validierung und Verwaltungsstatus.

RFC 9833 kennt awaiting-validation, awaiting-processing, admin-prohibited und rejected. Ein Auftrag kann genehmigt und validiert sein, während Arbeiten vor der Aktivierung fehlen. Wer awaiting-processing als „aktiv“ darstellt, ergänzt einen nicht belegten Ausgang.

Das Netz vergibt eine eigene Identität

RFC 9835 definiert ietf-ac-ntw. Das Modell ordnet die Servicereferenz dem tatsächlichen Netz-AC zu und enthält PE/SAP-Platzierung. Hier beginnt die portable Absicht, konkrete Providerressourcen zu binden.

Ob Service- und Netzschicht dieselbe Namenskonvention verwenden, erklärt die RFC ausdrücklich zur Deploymentfrage. Die Namen können gleich sein, müssen es aber nicht. Beweis ist die Referenzkante. Ein Join über bloße Textgleichheit kann nach Migration, Umbenennung oder Wiederverwendung Telemetrie mit dem falschen Auftrag verbinden.

Auch der Netzdatensatz beweist keine Anwendung. RFC 8969 trennt Service-, Netz- und Gerätemodelle und verlangt, Betriebszustand und Statistik nach oben zu spiegeln. Das Netzmodell drückt Orchestrierungsabsicht aus; die untere Ebene muss die Umsetzung quittieren.

Glue verbindet, liefert aber nicht

RFC 9836 ergänzt ietf-ac-glue, damit VPN-Modelle auf die richtigen AC-Identitäten zeigen. Dazu gehören das L3VPN-Servicemodell aus RFC 8299, das L2VPN-Servicemodell aus RFC 8466 und das L3VPN-Netzmodell aus RFC 9181. RFC 8345 und RFC 9543 liefern benachbarten Topologie- und Assurance-Kontext.

Eine Glue-Referenz belegt die modellierte Beziehung. Sie belegt weder Ressourcenreservierung noch Gerätekonfiguration, Erreichbarkeit, Weiterleitung oder SLA. Service-AC kann auf Netz-AC A zeigen, während VPN-Glue B nennt. Alle Objekte sind vorhanden und formal gültig; der Graph ist dennoch falsch.

Beabsichtigt ist nicht angewandt

RFC 8342 unterscheidet konfigurierte Werte, beabsichtigte Konfiguration und Betriebszustand. Verzögerung, Hardware, Protokolle und weitere Systeme können <intended> von <operational> trennen. Nur ihr Vergleich zeigt, welcher Teil der Absicht tatsächlich wirksam ist.

Die vollständige Kette authentifiziert und autorisiert den Auftraggeber, löst den Bearer auf, akzeptiert den Service-AC, ordnet ihn dem Netz-AC zu, wählt PE/SAP/Interface, bindet das richtige VPN, erzeugt Sollkonfiguration, beobachtet Anwendung und Zustand und misst schließlich OAM, Erreichbarkeit, Verkehr und Dienstergebnis getrennt.

RFC 7950 definiert YANG, ohne eine interne Architektur vorzuschreiben. RFC 9408 bietet einen Sicherheitsrahmen für YANG-Module. Diese Quellen belegen keinen konkreten Angriff; sie zeigen, warum Schreibrechte an richtige Schicht und richtiges Objekt gebunden werden müssen.

Heng Lus Idee einer minimalen Anfangsspezifikation mit lokalisierten Zukunftsentscheidungen passt hier: gemeinsame deterministische Referenzen, lokale Ressourcenentscheidungen. Der Vorrang des laufenden Codes fragt, ob diese Kanten im Produktivsystem fortbestehen. Realität statt Interessenvertretung begrenzt den Schluss: Vier RFCs liefern eine Kontrollkarte, kein Abnahmeprotokoll für einen Live-Anschluss.

Quellen