Zusammenfassung

  • Am 31. August 2026 billigte die IESG Revision 05 von Dynamic Flooding on Dense Graphs zur Veröffentlichung als Experimental RFC. Eine endgültige RFC-Nummer war im geprüften Stand noch nicht vergeben.
  • Ein Area Leader berechnet für Link-State-Updates einen spärlichen Flooding-Graphen. Der dichte Basisgraph für die Datenweiterleitung bleibt erhalten.
  • Sieben Kriterien sollen vor einem möglichen Aufstieg erfüllt werden, darunter drei unabhängige, interoperable Implementierungen und dokumentierte Betriebserfahrung. Die Zulassungsunterlagen nennen bislang eine IS-IS-Implementierung.
  • Konvergenz, Reduktion, Betriebsqualität und Robustheit sollen „akzeptabel“ sein, doch ein allgemeiner Zahlenwert fehlt. Betreiber müssen ihr Maß deshalb vor dem Versuch festschreiben.
  • Ein versioniertes Versuchsregister sollte Revision, Software, beide Graphen, Algorithmusentscheidungen, Grundgesamtheit, Fehlerfälle, temporäres Flooding, Rückfall und Entscheidungsbefugnis verbinden.

Gebilligt wurde ein Versuch

Die Entscheidung ist bewusst begrenzt. In der Link State Routing Working Group bestand starker Konsens, dass die Arbeit ein gemeinsames Experiment verdient. Das Problem ist handfest: Je dichter ein Link-State-Gebiet, desto mehr redundante Übertragungen kann klassisches Flooding erzeugen. Ein separat berechneter, dünnerer Graph könnte diesen Aufwand senken.

Der Ansatz trennt zwei Netze, die leicht verwechselt werden. Der Basisgraph enthält weiterhin die nutzbaren Links für den Datenverkehr. Der Area Leader berechnet dagegen einen Teilgraphen für die Verteilung von Zustandsinformationen und kündigt ihn über den Rahmen von RFC 9667 an. Dieser Graph muss alle erreichbaren Knoten umfassen, soll nach Möglichkeit zweifach zusammenhängend bleiben, keinen übermäßigen Durchmesser erzeugen und die Knotengrade verteilen.

Das Dokument zeigt einen anschaulichen Fall: Zehn vollständig verbundene Knoten ergeben 45 Kanten; der berechnete Flooding-Graph kommt mit zwölf aus, während sein Durchmesser von eins auf vier steigt. Das illustriert einen Zielkonflikt. Es ist weder ein Feldversuch noch ein Versprechen für Konvergenz oder Fehlertoleranz in einer anderen Topologie.

Auch der Reifegrad rechtfertigt Experimental. Der Shepherd-Bericht kennt eine IS-IS-Implementierung. Die Änderung greift erheblich in den Betrieb ein und baut auf dem ebenfalls experimentellen RFC-9667-Rahmen auf. Die Autoren beanspruchen keine Optimalität und schlagen ihren Algorithmus nicht als endgültig normierte Lösung vor. Das gemeinsame Dokument soll erst die Evidenz erzeugen, auf deren Basis später über Proposed Standard, Überarbeitung oder Ende entschieden werden kann.

Sieben Kriterien und mehrere offene Wertungen

Revision 05 verlangt mindestens drei unabhängige interoperable Implementierungen, dokumentierte Einführungs- und Betriebserfahrung, keine fundamentalen Einwände, geprüfte oder angepasste Sicherheitsbetrachtungen, akzeptable Betriebsqualität, akzeptable Konvergenz und Flooding-Reduktion sowie Robustheit bei Topologieänderungen.

Damit kann eine einzelne Vorführung nicht als fertiges Experiment gelten. Drei Produkte auf derselben Codebasis beweisen keine Unabhängigkeit. Ein Laborlauf liefert nicht allein durch seine Größe Betriebserfahrung. Und Interoperabilität reicht über Paketempfang hinaus: Der Leader muss den Graphen gemäß RFC 9667 kodieren, die teilnehmenden Knoten müssen ihre jeweilige Rolle übereinstimmend verstehen.

„Akzeptabel“ bleibt absichtlich ohne gemeinsame Sekunden- oder Prozentzahl. Ein Provider-Backbone, ein Rechenzentrums-Fabric und ein Forschungsnetz haben unterschiedliche Konvergenzbudgets und Ausfallfolgen. Eine globale Zahl könnte Scheingenauigkeit erzeugen.

Offenheit darf aber nicht zur nachträglichen Bewertungsfreiheit werden. Wer die Schwelle erst nach dem Lauf setzt, kann das Zeitfenster wechseln, den schlechtesten Rand der Verteilung ausblenden, Altgeräte aus dem Nenner entfernen oder eine verfehlte ursprüngliche Vorgabe als Erfolg umdeuten. Lokale Entscheidung ist nur dann belastbar, wenn Definition, Nenner, Grenzwert und zuständige Person vorher feststehen.

Implementierungsdetails formen den Graphen

Der zentrale Algorithmus lässt Freiheitsgrade: Tiefe der Suche, Reihenfolge der Nachbarn, Auflösung von Gleichständen und Auswahl zusätzlicher Endpunkte. Zwei Implementierungen können aus demselben Basisgraphen verschiedene Ergebnisse berechnen. Die Angabe „Dynamic Flooding aktiv“ macht Versuche daher nicht vergleichbar.

Auch der Area Leader ist eine konkrete Betriebsrolle. Nur er führt die Berechnung aus und kündigt den Graphen an. Welcher Router hatte die Rolle, welchen Wahlzustand sah der Betreiber, welche Link-State-Datenbank ging ein und wann wurde der neue Graph aktiv? Das Dokument erwartet, dass ein Managementmechanismus Leader und aktive Flooding-Nachbarschaften sichtbar macht, überlässt die Oberfläche aber der Implementierung.

Teilweise Einführung verändert den Nenner. Nicht unterstützende Knoten fluten weiterhin über alle Schnittstellen. Das hält die Kompatibilität aufrecht, verringert aber die Einsparung. Wer nur die aktualisierten Router auswertet, misst eine günstigere Population als das tatsächlich betriebene Gebiet.

Eine ruhige Topologie ist schließlich der leichteste Test. Link- und Knotenausfall, Verlust des Leaders, Teilung und Wiedervereinigung sowie rasche Änderungen erzwingen Neuberechnung und temporäres Flooding. Misslingt der Übergang, können Router veralteten Zustand erhalten und widersprüchliche Routen berechnen. Der durchschnittliche Nachrichtenwert einer stabilen Stunde sagt darüber wenig aus.

Das Versuchsregister kommt vor dem Ergebnis

Zuerst wird das Testobjekt bezeichnet: Draft-Revision, Umfang der RFC-9667-Unterstützung, Implementierung und Build, Reife, Lizenzmodell, Verantwortlicher und Zeitraum. Zu der Arbeit existiert eine IPR-Offenlegung. Ein Betreiber kann seine Prüfung als Entscheidungsabhängigkeit vermerken; dieser Beitrag zieht daraus keine rechtliche Schlussfolgerung.

Der Topologieblock hält Fingerabdruck des Basisgraphen, Knoten- und Kantenzahl, teilnehmende und ältere Knoten, Leader und Wahlverfahren, Fingerabdruck des berechneten Graphen sowie Ordnungs-, Gleichstands- und Endpunktparameter fest. Stabile Pseudonyme schützen sensible Adressen, ohne die Reproduzierbarkeit aufzugeben.

Der Messblock definiert, welches Ereignis die Konvergenzuhr startet und welche Beobachtung sie stoppt, welche Schnittstellen und Intervalle für das Flooding-Volumen zählen, welche Last pro Knoten, welcher Durchmesser, welche Gradverteilung und welcher Verlust toleriert werden. Durchschnitt, Verteilung, ungünstiger Rand und verworfene Läufe gehören zusammen.

Der Resilienzblock nennt vorab Link-, Knoten- und Leader-Ausfall, Partition und Heilung, schnelle Folgeveränderungen, Mischbetrieb sowie die Rückkehr zum klassischen Flooding. Pro Ereignis werden Erkennung, temporärer Modus, Graphwechsel, Zustandskonsistenz, Erholungszeit und manueller Eingriff verknüpft.

Der Entscheidungsblock hält Ausweiten, Eingrenzen, Pausieren oder Zurückrollen fest, nennt die befugte Stelle, verweist auf die vorherige Schwelle und terminiert Ausnahmen. Eine Korrektur ergänzt den Verlauf; sie überschreibt nicht den ersten fehlgeschlagenen Graphen.

RFC 7942 liefert dafür ein brauchbares Vorbild: Identität, Reife, Abdeckung, Versionskompatibilität, Lizenz, Erfahrung und Interoperabilitätsberichte sind nützliche, aber zeitabhängige Tatsachen. Sie gehören in ein lebendes Register außerhalb des unveränderlichen RFC und können später den verlangten Ergebnisbericht speisen.

Was die Billigung nicht belegt

Die geprüften Quellen belegen weder drei unabhängige Implementierungen noch einen benannten Produktionseinsatz, einen Feldgewinn oder einen Zwischenfall. Das Zehn-Knoten-Beispiel ist keine Leistungszusage. Ebenso wird die rechtliche oder wirtschaftliche Bedeutung der IPR-Offenlegung hier nicht bewertet.

Die Operationsprüfung ist präzise einzuordnen. Der OPSDIR-Review zu Revision 04 sah erhebliche Lücken bei schrittweiser Einführung, mehreren Algorithmen, Deployment und Knotenausfällen. Revision 05 ergänzte Operational Considerations. Das zeigt Wirkung der Begutachtung, nicht die dauerhafte Lösung jeder zukünftigen Implementierungsfrage.

Heng Lus Gedanke einer minimalen Anfangsspezifikation dient nur als begrenzter redaktioneller Test: Gemeinsame Regeln sollen deterministisch und vor Ort überprüfbar bleiben, spätere Betriebsentscheidungen müssen lokalen Eigentümer und Beleg behalten. Er liefert keine Tatsachen über diese IETF-Entscheidung oder ein bestimmtes Netz.

Die IESG hat somit keine Antwort zertifiziert. Sie hat eine gemeinsame Versuchsanordnung ermöglicht. Erst unabhängiger Code, vorab erklärte Maße und vollständig erhaltene Fehlschläge können daraus eine belastbare Antwort machen.

Quellen

  1. IESG – Bekanntmachung der Billigung
  2. IETF Datatracker – Dynamic Flooding on Dense Graphs, Revision 05
  3. IETF – Shepherd Write-up
  4. OPS Directorate – Last-Call-Review zu Revision 04
  5. RFC 9667 – Rahmen für Dynamic Flooding
  6. RFC 7942 – Status laufender Implementierungen
  7. IETF – IPR-Offenlegung 4044
  8. Heng Lu – Minimum Initial Specification