Zusammenfassung

  • Der aktuelle Text draft-xu-idr-fare-in-mpson-01 vom 16. August 2026 erweitert die Idee des bandbreitengewichteten ECMP aus FARE-BGP auf RoCE-NICs (RNICs) in mehr­ebenenfähigen Scale-out-Netzen.
  • Die betriebliche Aufgabe verbindet die Wahl zwischen isolierten CLOS-Ebenen an der RNIC mit der Grenze, Host-Routen nicht überall unbegrenzt vorhalten zu können.

Der IETF-Datatracker-Eintrag führt das Dokument als Fully Adaptive Routing Ethernet in Multi-Plane Scale-Out Networks. Es ist ein Internet-Draft mit beabsichtigtem Standards-Track-Status. Daraus folgt eine klare Grenze: Die IETF beschreibt Internet-Drafts als Arbeitsdokumente, die geändert, ersetzt oder ungültig werden können, nicht als abgeschlossene Standardentscheidung.

Der Text der Version -01 beschreibt eine RNIC, die an jeder Ebene mit einer unabhängigen CLOS-Fabric verbunden ist. Zwischen den Ebenen gibt es keine Links; deshalb entscheidet die RNIC, welche Ebene einen Flow oder ein Paket trägt. Der Vorschlag erweitert FARE-BGP — gewichtetes ECMP mit einer Path Bandwidth Extended Community — von Switches auf diese Schnittstelle. Vorgesehen sind getrennte BGP-Sitzungen zwischen der RNIC und den Leaf-Switches jeder Ebene, über die die Schnittstelle entfernte Erreichbarkeit und Bandbreiteninformationen für die gewichtete Wahl lernt.

Damit verlagert sich die Steuerungsfläche. Es geht nicht mehr nur darum, wie Fabric-Switches gleichwertige Wege verteilen. Entscheidend ist auch, ob die Werte an der Host-Schnittstelle vollständig und vergleichbar sind und nach Verlust der Erreichbarkeit einer Ebene zügig verschwinden. Der Text weist keinen Leistungsgewinn für einen KI-Cluster nach. Er bietet einen Mechanismus, um eine Entscheidung kontrollierbar zu machen, die die Architektur isolierter Ebenen ohnehin der Schnittstelle überlässt.

Skalierung ist die zweite Begrenzung. Als Beispiel nennt das Dokument 100.000 GPUs und vier Ebenen; jede Ebene kann bis zu 100.000 Host-Routen weitergeben. Die daraus folgenden 400.000 Routen auf jeder RNIC seien nicht praktikabel und vollständig auf Switches unerwünscht. Daher schlägt der Entwurf Tabellenunterdrückung vor. Eine Aggregation kann jedoch bestehen bleiben, nachdem eine entfernte RNIC über eine Ebene nicht mehr erreichbar ist. Um dieses Blackhole zu vermeiden, koppelt der Vorschlag Aggregation an eine explizite Unreachable-Advertisement; eine genannte Option ist ein Path-Bandwidth-Wert von null.

Das ist Entwurfslogik, nicht Nachweis eines Einsatzes oder einer Interoperabilität.