Zusammenfassung

  • was-the-last-lie-accepted sagt nur, ob das zuletzt empfangene Link Information Element an einer Schnittstelle akzeptiert wurde. ThreeWay, ZTP-Hierarchie, TIE-Synchronität, RIB/FIB und reale Zustellung bleiben unbewiesen.
  • Ein erfolgreicher Clear-Aufruf startet den Neuaufbau. Erst nach erneuter Prüfung von Zustand, Datenbank, Routen, Hardware und Lieferung darf von Wiederherstellung gesprochen werden.

Ein enges, aber wichtiges Versprechen

RFC 9719 definiert ein NMDA-kompatibles YANG-1.1-Modell für RIFT und erweitert das IETF-Routing-Modell. Darin ist was-the-last-lie-accepted schreibgeschützter Betriebszustand. True bedeutet, dass der zuletzt empfangene LIE die Annahmeprüfung bestand. Bei Ablehnung liefern last-lie-reject-reason und neighbor-error weitere Hinweise.

Die Aussage betrifft genau eine Nachricht an einer Schnittstelle. Sie sagt nicht, dass der Nachbar diesen Knoten bestätigt hat, die Adjazenz ThreeWay erreichte, ZTP die beabsichtigte Ebene auswählte, die Topologiedaten vollständig sind, eine Route im Forwarding installiert wurde oder ein Paket ankam.

RFC 9692 trennt diese Schritte im Zustandsautomaten. TwoWay setzt bereits einen gültigen LIE voraus, jedoch noch keinen gültigen ThreeWay-LIE. Erst ThreeWay macht die Adjazenz ankündbar und erlaubt TIE-, TIDE- und TIRE-Austausch. Annahme prüft einen Eingang; ThreeWay belegt Gegenseitigkeit.

Das Modell als Ermittlungsplan

RFC 9719 stellt dafür mehrere eigenständige Beobachtungen bereit: Schnittstellenzustand und Ablehnungsgrund, Adjazenz-FSM, gesendete und empfangene ZTP-Angebote, bestes Angebot und Entfernung, Zähler und Warteschlangen für LIE/TIE/TIDE/TIRE, lokale TIE-Datenbank, SPF-Zeiten und auslösenden TIE sowie Fehlerbenachrichtigungen.

Bei Ablehnung werden Grund, Peer, Meldung und Zeitlinie vor jeder Änderung gesichert. Implementierungslogs dürfen ergänzen, aber nicht den standardisierten Zustand ersetzen.

Bei Annahme folgt die Frage, ob ThreeWay erreicht und gehalten wird. Ein Stopp in TwoWay widerspricht dem ersten Befund nicht. Er lokalisiert das Problem zwischen gültiger Entdeckung und gegenseitiger Bestätigung.

Danach werden Angebote und Hierarchie geprüft. Ein akzeptabler LIE garantiert weder die richtige Ebene noch die beabsichtigte Nord-Süd-Ausrichtung. Received offer, best offer und removal reason sind getrennte Entscheidungen.

Erst dann kommt die Synchronisation: TIE-Datenbestand, TIDE/TIRE-Bewegung, Warteschlangen, Nachbarzahl und SPF-Auslöser. Auch eine stabile Adjazenz kann mit einer unvollständigen Informationsbasis koexistieren.

Die letzte Prüfung liegt außerhalb des RIFT-Modells. RFC 9692 schreibt nicht vor, wie die Weiterleitung programmiert wird. RIB, FIB, ASIC-Zähler und ein echter Lieferprobe sind daher eigene Beweise. Das Kontrollmodell zeigt, was RIFT annimmt; das Paket zeigt, was tatsächlich geschieht.

Clear ist kein Abschlusskriterium

clear-neighbor und clear-all-neighbors beenden eine oder alle Nachbarverbindungen an der Schnittstelle. Eine erfolgreiche Antwort bestätigt die Annahme des Befehls, nicht den erfolgreichen Neuaufbau. Die Sicherheitsbetrachtung warnt, dass unbefugte Clears wiederholte Rekonstruktionen und Instabilität verursachen können.

Vor einem Clear wird der Zustand gesichert, danach die kleinste vertretbare Aktion gewählt und anschließend die ganze Kette erneut geprüft: LIE, ThreeWay, Angebote, TIE, SPF, Routeninstallation, Hardware-Weiterleitung und Lieferung. Ein Reset kann veralteten Zustand entfernen, aber auch die entscheidende Spur vernichten.

Der eigentliche Gewinn

Automatisierung kann wiederholte Ablehnungen erkennen, nach ThreeWay die Datenbank prüfen, einen auslösenden TIE mit der SPF-Dauer verknüpfen und Betriebsangebote mit der Konfigurationsabsicht vergleichen.

Sie darf jedoch kein lokales Boolean zum grünen Gesamtstatus erheben. RFC 9719 macht nicht eine Antwort universell, sondern die Grenzen mehrerer Antworten maschinenlesbar.