Zusammenfassung

  • RFC 9692 verteilt detaillierten Link-State nach Norden und aggregierte Defaults nach Süden. Ein Fallen Leaf ist die Ausnahme, bei der das Aggregat bestehen bleibt, aber in einer Plane für ein Ziel nicht mehr stimmt.
  • Positive, nicht-transitive Disaggregation zieht Verkehr zu noch erreichbaren Eltern. Negative, transitive Disaggregation entfernt ungeeignete Next Hops und kann bis zum ingress Leaf gelangen.
  • Ein negatives Prefix TIE, eine ruhige Datenbank oder ein korrektes RIB beweist weder die Hardware-FIB noch die tatsächliche Dienstzustellung.

Die problematische Meldung lautet nicht „Default fehlt“, sondern „Default genügt nicht mehr“. RFC 9692 wurde im April 2025 als IETF Standards Track veröffentlicht und definiert RIFT für Clos- und Fat-Tree-Fabrics. North TIEs tragen Adjazenzen und Präfixe zu den Spines. South TIEs tragen gewöhnlich Adjazenzen, IPv4-/IPv6-Defaults und notwendige disaggregierte Ausnahmen. Der RFC-Datensatz beschreibt die Mischung als Link-State nach oben und Distance-Vector nach unten.

Das spart Zustand an der großen Zahl von Edge-Geräten. Ein Default verrät jedoch nicht, dass eine Plane ihr letztes Stück Konnektivität zu einem bestimmten Leaf verloren hat. RFC 9692 nennt ein Leaf „fallen“, wenn es nur noch von einer Teilmenge der Top-of-Fabric-Knoten erreicht wird. Da ein ingress Leaf die Plane oft früh auswählt, muss die Ausnahme bis zu diesem Entscheidungspunkt gelangen.

Positiv anziehen, negativ ausschließen

Positive Disaggregation beginnt bei einem Router, der das Präfix noch erreicht. Er kündigt es spezifischer in einem positiven South Prefix TIE an. Longest Prefix Match zieht den Verkehr zu den fähigen Eltern. Die Ankündigung ist nicht transitiv und bleibt auf eine Fabric-Ebene begrenzt. Sie reicht aus, wenn die erreichbaren ToFs gemeinsam alle relevanten Knoten der defekten Plane abdecken.

Negative Disaggregation meldet dagegen, dass ein Elternknoten das Präfix nicht erreicht. Der negative Eintrag ist nur innerhalb eines kürzeren positiven Aggregats wirksam. Er erbt dessen Next Hops und entfernt die Nachbarn, die negativ angekündigt haben. Im abstrakten RIB bleiben Negativroute und Auswahlzustand erhalten; in die FIB gelangen die verbleibenden positiven Anweisungen.

Ein Zwischenknoten propagiert den negativen Eintrag nur dann weiter nach Süden, wenn kein child das Präfix ankündigt und alle parents negativ angekündigt haben. Zieht ein parent sein Negativ zurück, muss auch der transitive Eintrag verschwinden.

RFC 9692 nennt zwei Auslöser. Am ToF wird die Erreichbarkeit aus allen North Node TIEs einschließlich horizontaler Links mit dem normalen Southbound-SPF verglichen. Die Differenz sind Fallen Leaves und ihre Präfixe. Weiter unten kann beim Anfügen von Präfixen sichtbar werden, dass alle vom positiven Aggregat geerbten Next Hops durch negative Ankündigungen entfernt wurden. Beides sind Control-Plane-Berechnungen.

Vom Detektor bis zum Dienst

Der erste Nachweis ist Link- oder Adjazenzstatus. RIFT kann BFD verwenden; RFC 5880 und RFC 5881 definieren schnelle bidirektionale Fehlererkennung. Sie benennt nicht automatisch jedes betroffene Leaf-Präfix.

Danach folgen geänderte Node/Prefix TIEs, ihre Verteilung zwischen Planes, die Fallen-Leaf-Berechnung, die Disaggregat-Ankündigung und das SPF/RIB-Ergebnis. Erst der nächste Nachweis betrifft die tatsächlich programmierte Hardware-FIB. RFC 9719 modelliert RIFT-Konfiguration und -Zustand mit Interfaces, Nachbarn, TIE-Datenbanken und SPF-Statistiken. Das ist wertvolle Protokollbeobachtung, aber keine vollständige Hardware-Attestierung.

Anschließend muss der Datenpfad geprüft werden. Ein aktives Verfahren wie TWAMP aus RFC 5357 zeigt, was ein Probe-Paar in einem Zeitraum erlebt hat. Tests sollten ingress Leafs, Zielpräfixe, Adressfamilien und ECMP-Hashes variieren. Erfolg belegt trotzdem weder alle Alternativen noch Kapazität unter Last oder Anwendungszustand.

RFC 9696 ergänzt, dass negative Disaggregation vollständiges Präfixwissen am ToF braucht und FIB-Programmierung rekursiv sowie komplex sein kann. ECMP allein garantiert dort weder Zustellung noch begrenzte Latenz. Das ist Anwendbarkeitsberatung, kein Ergebnis einer benannten Implementierung.

Der aktuelle Errata-Datensatz zu RFC 9692 enthält eine für Dokumentaktualisierung gehaltene technische Korrektur zu ausgelassenem Thrift-Material in Abschnitt 7.2. Sie ändert das Fallen-Leaf-Verfahren nicht.

Heng Lus Texte zu Running-Code-Vorrang, minimaler Anfangsspezifikation und Realitätsebenen liefern eine redaktionelle Perspektive: Regel, Implementierung und Beobachtung dürfen nicht füreinander ausgegeben werden. Sie sind keine IETF-Anforderungen und kein Deployment-Nachweis.

Die begrenzte Schlussfolgerung lautet daher: RFC 9692 definiert eine plausible Reparatur für ein zu breites Default. Operativ abgeschlossen ist sie erst, wenn Detektion, TIE-Verteilung, Berechnung, FIB, Probe und Dienst getrennt bestätigt wurden – und beim Rückzug der Ausnahme erneut.