Zusammenfassung

  • RFC 9502 liefert eine kontrollierte Zuordnung von IP-Präfixen zu einem Flexible Algorithm; sie liefert keinen End-to-End-Nachweis über Verkehr oder Dienstgüte.
  • Besonders wichtig ist der negative Befund: Nichtteilnahme oder Nichtinstallation kann regelkonformes Sicherheitsverhalten sein und muss als Ergebnis dokumentiert werden.

Der problematischste Satz nach einer Netzänderung lautet oft: „Der neue Pfad ist aktiv.“ Er ist zu kurz, um prüfbar zu sein. Aktiv kann eine Flexible Algorithm Definition sein. Aktiv kann eine einzelne IPv4-Berechnung auf einem Router sein. Aktiv kann eine FIB-Route sein. Der Satz kann aber auch als Behauptung über einen Kundenfluss, eine Inter-Area-Strecke oder eine Verfügbarkeitszusage verstanden werden. Ohne Gegenstand, Knoten, Datenebene und Zeitfenster ist er keine technische Feststellung, sondern eine riskante Verdichtung.

RFC 9502 hält die nötigen Zwischenstufen offen. Sie erweitert IGP Flexible Algorithms auf IPv4- und IPv6-Prefix-Reachability. Das Präfix wird damit Input für eine algorithmspezifische Berechnung, nicht direkt ein Befehl zur Weiterleitung. Wer aus der Konfiguration eine Lieferzusage ableitet, überspringt die Stufen, die die Spezifikation gerade voneinander trennt.

Die erste Stufe ist die FAD. Nach RFC 9350 müssen teilnehmende Knoten über die Definition übereinstimmen. Kann ein Knoten sie nicht unterstützen oder validieren, nimmt er nicht an diesem Algorithmus teil. Diese Nichtteilnahme ist keine nebensächliche Lücke in einem Inventar. Sie verändert die Berechnungsmenge. Ein Operator sollte darum nicht nur den Identifier erfassen, sondern Definition, Version, Zustimmung und Ablehnungen je Knoten.

Die zweite Stufe ist datenebenenbezogen. RFC 9502 behandelt IPv4 und IPv6, doch die Teilnahme erfolgt je IP Data Plane. Ein Router kann in einer Ebene beteiligt und in der anderen ausgeschlossen sein. Ein Programm, das „Algorithmus 128 ausgerollt“ meldet, kann daher einen bedeutenden Unterschied verschweigen. Für die Führungsebene ist das keine Implementierungsfußnote: Ein Dienst mit dual stack kann genau an dieser Stelle eine asymmetrische Ausfallfläche erhalten.

Die dritte Stufe ist die Berechnung. Topologie, Metrik, Constraints, administrative Link-Einschlüsse und lokale Auswahlregeln bestimmen, ob und wie ein Präfix erreichbar wird. Sichtbarkeit eines Präfixes ist nicht gleich gültiger Pfad, gültiger Pfad nicht gleich bevorzugter Pfad, bevorzugter Pfad nicht gleich Installation. Nichtteilnehmer werden bei der Flex-Algorithm-Berechnung ausgeschnitten. Wer nur eine Präfix-Ankündigung betrachtet, hat deshalb nicht einmal die gesamte Ausgangslage der Berechnung bewiesen.

Gerade das Nicht-Installieren verdient eine eigene Sprache. RFC 9502 verlangt bei widersprüchlichen Informationen für dasselbe Präfix unter unterschiedlichen Algorithmen, die Information zu ignorieren und keine entsprechende Route zu installieren. In einem Dashboard wirkt eine fehlende Route schnell wie ein Defekt, den ein Statusbericht kaschieren möchte. Sie kann aber die korrekte Abwehr einer mehrdeutigen Entscheidung sein. Die Frage lautet dann nicht „Warum ist der Bildschirm nicht grün?“, sondern „Welche Schutzregel oder welcher Konflikt hat die Installation verhindert?“

Die FIB ist die vierte Stufe. Sie zeigt eine echte lokale Forwarding-Entscheidung. Zugleich weist RFC 9502 darauf hin, dass eine IP-Datenebene für dasselbe Präfix nicht gleichzeitig Pfade mehrerer Algorithmen verwendet. Zwei sichtbare Algorithmusbezeichnungen sind somit kein Nachweis zweier gleichzeitig produktiver Wege. Der belastbare Nachweis braucht Router, Tabelle, Präfix, Next Hop, Zeitpunkt und, bei Änderung, den Vergleich vor und nach dem Eingriff.

Danach erst folgt der Verkehrsnachweis. Ein Counter, Flow-Record oder synthetischer Test kann zeigen, dass ein bestimmter Verkehr in einem definierten Zeitraum beobachtet wurde. Er kann mehr beweisen als eine FIB, aber nicht beliebig viel: Ein einzelner Test ersetzt weder eine SLO-Messung noch eine Aussage über jede Anwendung. Gute Governance zwingt niemanden zu einer Totalbehauptung. Sie ordnet jeder Behauptung die passende Evidenz und den verantwortlichen Eigentümer zu.

Praktisch empfiehlt sich eine Beweiskette mit fünf getrennten Artefakten: erstens FAD samt Constraints und Akzeptanz; zweitens Teilnahme-Matrix je Knoten und IPv4/IPv6; drittens Berechnung für kritische Präfixe, einschließlich Ausschlussgrund; viertens FIB-Snapshots an Kontrollpunkten; fünftens Verkehrs- oder Servicemessung mit Fenster. Ein Freigabegremium muss ausdrücklich entscheiden, welches Artefakt für welchen Fortschritt genügt. Aus einem Artefakt darf die Aussage des nächsten nicht stillschweigend abgeleitet werden.

Das entspricht Heng Lus Argument in der Notiz zur minimalen Anfangsspezifikation. Ein Mechanismus, der eine künftige Entscheidung lokalisiert, ersetzt diese Entscheidung nicht. Eine FAD grenzt ein, welche Berechnung akzeptabel wäre. Sie erzwingt weder Gerätefähigkeit noch Teilnahme noch Installation. Die lokalen Entscheidungen aus einer Spezifikation herauszuschreiben, macht ein System nicht zentral beherrschbarer; es macht Berichte weniger wahr.

Die Überlegung zu running code verschärft den Punkt. Laufender Code ist relevante Evidenz, aber keine Vollmacht, nicht gemessene Wirkungen zu behaupten. Eine FIB-Zeile ist ein guter Nachweis für eine lokale Entscheidung, nicht für ein Vertragsergebnis. Die Reichweite des Belegs muss der Reichweite des Versprechens entsprechen.

Das IANA-Register für IGP Parameters stellt unter anderem 128–255 für Flexible Algorithms bereit. Es schafft einen öffentlichen Namensraum und verhindert Identifier-Kollisionen. Es ist kein Betriebsprotokoll: Das Register kennt keine FAD-Akzeptanz, keine IPv6-Teilnahme und keine Pakete. Ein registrierter Name darf daher nicht zu einem Gütesiegel für tatsächlich gelieferten Verkehr werden.

RFC 8174 hilft bei der Lesart normativer Wörter. Ein MUST NOT install erklärt eine vorgeschriebene Unterlassung; es erzeugt keine Beobachtung über Dienstqualität. Diese Unterscheidung ist für Risikoausschüsse wesentlich. Sie können klare, nachweisbare Aussagen verlangen, ohne Protokollsprache zu Marketingprosa zu machen.

Bei einer Störung ist diese Kette auch der Unterschied zwischen Reparatur und Erinnerung. Ohne gespeicherte FAD, Teilnahme und FIB ist später schwer festzustellen, ob der Fehler ein Konflikt, eine fehlende Fähigkeit, eine Änderung der Constraints oder ein tatsächlicher Datenpfadfehler war. Eine Organisation, die diese Stufen bewahrt, kann begründet zurückrollen. Eine Organisation, die nur „aktiv“ protokolliert, muss raten.