Zusammenfassung

  • RFC 9757 kann BGP-Sitzungen, explizite Peer-Routen, Präfixankündigungen und Raw- oder Tunnel-Forwarding über PCEP koordinieren; PCInitiate dokumentiert dabei Controller-Absicht, PCRpt nur eine begrenzte Aussage des PCC.
  • Die operative Beweiskette muss über Autorität und Epoche, Synchronisierung, beidseitige BGP-Identität, Policy-Annahme, RIB/FIB-Installation, Paket-Canaries sowie geordnete Wiederherstellung und Bereinigung weiterführen.

Ein Controller kann eine makellose Reihe von Bestätigungen erhalten, obwohl der Dienst nicht nachgewiesen ist. Ein Router meldet die Verarbeitung der Peer-Anweisung. Zwischenknoten bestätigen ihre expliziten Routen. Edge-Geräte berichten, sie hätten die Präfixe gesendet. Pfadname und Controller-Kennung stimmen, der Bildschirm wird grün. Diese Abfolge zeigt dennoch nicht zwingend, dass der entfernte BGP-Sprecher die Route angenommen hat, dass jede Forwarding-Tabelle den vorgesehenen Next Hop enthält, dass der Übergang schleifenfrei war oder dass ein einziges Paket den Pfad durchlaufen hat.

Bei RFC 9757 ist diese Grenze besonders bedeutsam, weil die Spezifikation PCE-as-a-Central-Controller in die alltägliche Mechanik eines Native-IP-Netzes erweitert. Das Dokument wurde als Experimental veröffentlicht und beschreibt Pfade aus BGP-Sitzungen, Host-Routen und Präfixankündigungen. Die Einträge beim RFC Editor und im Datatracker belegen Identität und Status. Der RFC bittet ausdrücklich um Erfahrungen aus Implementierung und Betrieb zu Auswirkungen, Skalierbarkeit und Stabilität. Vergebene Objekte und normative Abläufe sind daher kein Beleg für Verbreitung oder Produktionserfolg.

Drei Anweisungen, ein Pfadname, keine atomare Transaktion

Eine Native-IP-Anweisung in PCInitiate enthält SRP, LSP, eine Central Controller Instruction mit Object-Type 2 und genau eines von drei neuen Objekten. BPI beschreibt den BGP-Peer. EPR beschreibt eine Host-Route zu diesem Peer. PPA beschreibt die Präfixe, die ihm angekündigt werden sollen. Ein Symbolic Path Name korreliert verteilte Anweisungen als einen Ende-zu-Ende-Pfad; CC-ID unterscheidet die Controller-Anweisung innerhalb der PCEP-Sitzung.

Diese Korrelation ist stark, macht die Ausführung aber nicht atomar. Ein Pfad kann an verschiedenen Geräten verschiedene Objekte benötigen, und jedes PCC meldet lediglich die ihm zugewiesene Arbeit. PCRpt kann eine Anweisung bestätigen und an der Zustandssynchronisierung teilnehmen. Durch die Wiederholung desselben Objekts wird das PCC jedoch nicht zum unabhängigen Zeugen. Es berichtet, was seine PCEP- und lokalen Steuerungsmodule verarbeitet zu haben glauben.

Die Beweisgrenze beginnt vor der ersten Anweisung. Beide PCEP-Teilnehmer müssen Path Setup Type 4 und das Native-IP-Capability-Bit ankündigen. Widersprüchliche Aushandlung führt zu definierten Fehlern und Sitzungsende. Das verhindert eine unbemerkte Fähigkeitsabweichung, beweist aber weder eine aktuelle Topologie beim PCE noch die organisatorische Berechtigung, eine vollständige PCC-Menge oder ein sicheres Änderungsfenster.

Zusätzlich zur Authentisierung des PCE und zum Schutz der PCEP-Kommunikation müssen Betriebsteams die authentisierte Controller-Identität, den genehmigten Umfang, den Entscheidungsverantwortlichen und die Controller-Epoche festhalten. Auch ein kryptografisch geschützter Befehl kann falsch, veraltet oder außerhalb des Mandats sein.

Für BGP braucht es Aussagen von beiden Enden

BGP Peer Info enthält Peer-AS, lokale und entfernte Adresse, EBGP-TTL, Status oder Fehler und das T-Bit zur Wahl der Forwarding-Strategie. Die Adressen müssen für diesen Native-IP-Einsatz reserviert sein und dürfen nicht mit einer manuell aufgebauten Sitzung geteilt werden. Das empfangende PCC versucht den Sitzungsaufbau und meldet Fortschritt, Erfolg oder Fehler.

Entscheidend ist „meldet“. RFC 9757 ändert nicht die in RFC 4271 definierte BGP-Zustandsmaschine. Es reicht ausgewählte Parameter an das lokale BGP-Modul weiter; viele weitere Werte stammen aus Defaults. Der BPI-Status established ist ein nützlicher Nachweis eines Geräts, aber keine bilaterale Sitzungsurkunde. Eine Betriebsquittung sollte Adressen und AS-Nummern beider Seiten, AFI/SAFI, Transportschutz, Policy-Instanz, Router-Identitäten, Sitzungsgeneration und Aufbauzeiten zusammenführen. Sonst können eine alte Sitzung, ein unerwarteter Standardwert oder der falsche Peer dasselbe beruhigende Etikett tragen.

RFC 8821 liefert die umfassendere CCDR-Architektur, in der mehrere BGP-Sitzungen die Native-IP-Pfadwahl erzeugen. Das hebt Import- und Export-Policies nicht auf. Weist PPA ein Edge-PCC an, Präfixe an einen bestimmten Peer anzukündigen, fordert RFC 9757 nach erfolgreichem Senden einen Bericht. „Gesendet“ endet auf der lokalen Seite. Es belegt weder Zustellung noch Adj-RIB-In beim Gegenüber, Policy-Annahme, Best-Path-Auswahl, Weitergabe oder Nutzung im Forwarding. Bei folgenreichen Änderungen sollten deshalb die Kennung des ausgehenden UPDATE, Empfangsnachweis des Peers, genaue Policy-Revision, Loc-RIB-Auswahl und die letztlich von Paketen getroffene FIB-Position verbunden werden.

Eine Routenbestätigung ist kein Auslesen der Linecard

EPR verbindet Peer-Aufbau mit Erreichbarkeit. Es installiert Host-Routen zu Peer-Adressen, typischerweise mit höherer Präferenz als dynamische IGP-Routen und niedrigerer als manuell oder anderweitig statisch konfigurierte Routen. Das PCC muss die Erreichbarkeit des Next Hop prüfen. Um eine vorübergehende Schleife zu vermeiden, fügt der PCE EPR-Zustand in umgekehrter Ende-zu-Ende-Reihenfolge hinzu, entfernt ihn in Vorwärtsrichtung und installiert bei einer Änderung den neuen Next Hop, bevor er die alte Anweisung löscht.

Diese Reihenfolge ist eine prüfbare Kontrollfläche. Ein Protokoll sollte Pfadversion, Geräteabhängigkeiten, Versand- und Bestätigungszeiten, Next-Hop-Auflösung sowie den Zeitpunkt der Entfernung alten Zustands enthalten. Ein erfolgreicher PCRpt kann zeigen, dass das PCC die EPR-Operation gemäß seiner Implementierung angenommen oder abgeschlossen hat. Unabhängige RIB- und FIB-Lesevorgänge bleiben nötig, ebenso Adjazenzstatus und Paketbeobachtung.

Eine Route kann im Kontrolltabellenwerk stehen und trotzdem den Präferenzvergleich verlieren, an der Hardwareprogrammierung scheitern, auf eine alte Adjazenz zeigen oder erst eintreffen, nachdem ein anderes Gerät den alten Pfad bereits entfernt hat.

Für Raw und Tunnel gilt dieselbe Trennung. Raw leitet anhand des ursprünglichen Ziels weiter; die Pfadbindung ist mäßig, und Verkehr von einem anderen Eingang kann einen bevorzugten Abschnitt teilen. Tunnel nutzt IP-in-IP zwischen gewähltem Ein- und Ausgang, um dieses Paar enger zu binden. Das T-Bit hält die Wahl fest. Es beweist weder Kapselung und Entkapselung noch MTU-Sicherheit, Quellvalidierung, Endpunktidentität oder den tatsächlich durchlaufenen Pfad. Ein Canary sollte Eingang, Verkehrsklasse, Größe, Zeitstempel und erwarteten Ausgang tragen; bei Tunnel braucht es getrennte Belege von beiden Endpunkten.

Im Fehlerfall wird Korrelation zu einer Zeitfrage

RFC 9757 behandelt BPI, EPR und PPA mit demselben Symbolic Path Name als Attribute eines Pfades in der LSP-Datenbank und nutzt die Synchronisierung aus RFC 8232. Das stateful Modell aus RFC 8231, die PCE-initiierten Verfahren aus RFC 8281 und die zentralen Anweisungen aus RFC 9050 liefern den Rahmen für Zustand, Delegation und Timeout.

Synchronisierung beweist, was innerhalb einer bestimmten Datenbankversion und eines Sitzungskontexts gemeldet wurde. Sie friert das Netz nicht ein. Fällt ein PCC aus der Kontrolle, muss der PCE auf aktiven PCCs neu berechnen und ausrollen, ohne vorübergehende Schleifen zu erzeugen. Fällt der PCE aus, können Anweisungen neu delegiert werden; bestehender Zustand kann bis zum State Timeout Interval fortbestehen. Die Evidenzkette braucht daher Controller-Epoche, PCEP-Sitzungsgeneration, Datenbankversion, PCC-Mitgliedermenge und den exakten Zeitpunkt jedes Autoritätswechsels.

Auch Bereinigung ist kein einzelner Löschknopf. Der PCE sendet explizite Entfernungsanweisungen für PPA, EPR und BPI. Der sichere Nachweis folgt den Abhängigkeiten: die beabsichtigten Ankündigungen sind zurückgezogen; veraltetes Forwarding ist verschwunden, ohne den verbleibenden Pfad zu früh zu kappen; BGP-Sitzung und Konfiguration sind entfernt; in RIB, FIB, Tunnel-Tabellen und synchronisierter Datenbank bleibt kein Rest. Der letzte Zeuge ist ein negativer und positiver Verkehrstest: Der stillgelegte Pfad trägt den Canary nicht mehr, der überlebende oder wiederhergestellte Pfad weiterhin.

Heng Lus Running-Code Primacy bietet dafür eine redaktionelle Disziplin: Koordinationsartefakte dürfen Implementierung, Validierung, Betrieb und Nutzung nicht überstimmen. Minimum Initial Specification trennt ein gemeinsames technisches Vokabular von späteren lokalen Entscheidungen. Für RFC 9757 heißt das, die wertvolle Korrelation anzuerkennen, ohne dem Protokoll die Zertifizierung unbeobachteter Tatsachen aufzubürden.

Das Führungskonto benötigt zehn verbundene Belege: Autorität und Epoche; gegenseitige Capability; abgeschlossene Synchronisierung; Anforderung und Bericht je Objekt; bilaterale BGP-Identität; Policy-Annahme; RIB/FIB-Realisierung; Raw/Tunnel-Zustand; Paket- und Service-Canaries; Neuberechnung, Rücknahme und Rollback. RFC 9757 verbessert die erste Hälfte. Sein Wert liegt nicht darin, PCRpt zum Paketbeweis zu machen, sondern die Grenze sichtbar zu halten, bevor ein grüner Controller-Bildschirm eine unbelegte Geschäftsentscheidung trägt.

Quellenregister

Der aktuelle Dokumentstand lässt sich über die Errata-Suche zu RFC 9757 prüfen. Die PCEP-Grundlage liefert RFC 5440; RFC 8408 und RFC 8283 ergänzen den PST- und PCECC-Kontext. Die redaktionellen Maßstäbe nutzen außerdem Heng Lus Reality, Not Advocacy und Reality Layers.