Zusammenfassung

  • RFC 9917 ist ein IETF Standards Track Proposed Standard, veröffentlicht im Januar 2026. Er aktualisiert RFC 9350 und RFC 9843 und führt Reverse-Affinity-Constraints ein, die Extended Administrative Groups an der Rückwärtskante auswerten.
  • Der Betreiber muss Telemetrie, Set-/Clear-Schwellen, Codierungsprüfung, den gewinnenden FAD, Regelreihenfolge, Support und Rollback gemeinsam beherrschen. Die Spezifikation erledigt keine dieser Betriebsaufgaben automatisch.

Der Mechanismus

Das Modell unterscheidet gerichtete Kanten: eine Vorwärtskante, über die Verkehr abfließt, und eine Rückwärtskante, über die das entfernte Ende seine Beobachtung ausdrücken kann. Ein Empfänger am entfernten Ende kann Eingabefehler feststellen; CRC-Fehler nennt RFC 9917 lediglich als Beispiel. Überschreitet die Beobachtung einen vom Betreiber definierten Schwellenwert, kann auf der Rückwärtskante eine Extended Administrative Group gesetzt werden. Die Pfadberechnung kann daraus ableiten, dass die korrespondierende Vorwärtskante in einer Flex-Algorithm-Topologie nicht verwendet werden soll.

Damit wird kein allgemeiner Fehlerdetektor vorgeschrieben. RFC 9917 sagt auch nicht, wie ein Hersteller Live-Telemetrie automatisch in eine Administrative Group übersetzt, und definiert keine universellen Schwellenwerte. Reverse Affinity macht einen physischen Link nicht symmetrisch; sie liefert ein gerichtetes Policy-Signal.

Drei Constraint-Familien

Für IS-IS und OSPF beschreibt RFC 9917 drei Reverse-Admin-Group-Constraints. Exclude schließt eine Vorwärtskante aus, wenn die relevante Gruppe vorhanden ist. Include-any verlangt, dass mindestens eine angegebene Gruppe passt. Include-all verlangt, dass alle angegebenen Gruppen passen. Diese Semantik darf nicht mit der Zusicherung verwechselt werden, dass jeder Router jeden Constraint in jedem Flex-Algorithm unterstützt.

Auch die negative Prüfung gehört zur Abnahme. Fehlerhafte Längen der Reverse-Affinity-Sub-TLVs werden ignoriert. Bei doppelten Vorkommen gelten die in RFC 9917 für IS-IS und OSPF festgelegten Empfängerverhalten. Die Spezifikation ist hier keine Einladung, ein eigenes Verhalten zu erfinden oder aus einem Test mit einem Protokoll auf das andere zu schließen.

Reihenfolge ist Teil der Funktion

Die Regeln 8, 9 und 10 erweitern ein geordnetes Pruning-Register. Vor ihnen liegen die bestehenden Regeln aus RFC 9350 und RFC 9843. Die relative Reihenfolge bestehender Regeln darf nicht geändert werden; Regeln dürfen nicht gelöscht, zusammengeführt oder wiederholt werden. Der gewinnende FAD muss daher zuerst eindeutig ermittelt werden, danach muss die Implementierung die geordnete Pruning-Kette anwenden. Ein syntaktisch akzeptierter FAD beweist noch keine übereinstimmende Topologie auf allen Routern.

RFC 7308 ist für die Extended-Administrative-Group-Codierung maßgeblich. In einer Testumgebung sollte deshalb nicht nur die Route, sondern auch Länge, Wert, Auftreten und Weitergabe der Sub-TLV geprüft werden. Bei gemischter Unterstützung können formal akzeptierte Informationen zu unterschiedlicher Pruning-Wirkung führen; konkrete Herstellerunterstützung ist aus diesen RFCs nicht abzuleiten.

Flooding, Rekalkulation und Stabilität

Ein Schwellenwert, der bei jeder Messprobe zwischen gesetzt und gelöscht wechselt, kann IGP-Flooding und wiederholte Pfadberechnung auslösen. RFC 9917 nennt getrennte Set- und Clear-/Unset-Schwellen als mögliche Dämpfung und verweist außerdem auf gewöhnliches IGP-Throttling. Das sind Kontrollmöglichkeiten, keine normativ vorgegebenen Betriebswerte. Zu messen sind mindestens Änderungsrate der Group, Flooding-Volumen, Rekalkulationsrate, Konvergenzzeit und die Qualität des Ersatzpfads.

Analyse von Theo March

Die Betreiberentscheidung beginnt mit der Frage, wem die Telemetrie gehört. Danach folgen Schwellenwertverantwortung, Validierung der RFC-7308-Codierung, Konsistenz des gewinnenden FAD, Unterstützung für IS-IS/OSPF und die drei Constraint-Familien, Beobachtbarkeit und Rollback. Ein belastbarer Versuch vergleicht Vorwärts- und Rückwärtsattribute sowie die berechnete Topologie in beiden Richtungen: beim Setzen und beim Löschen der Affinität.

Dieser Beitrag behandelt nicht PCEPS-Replay und TLS-1.3-Early-Data-Grenzen aus RFC 9916, nicht den DHCPv6-Lease-Lebenszyklus aus RFC 9915, nicht RPL-Route-Projection aus RFC 9914 und nicht RAW-Recovery aus RFC 9912. Seine These ist enger: Rückwärts gerichtete Link-Evidenz kann als geordneter IGP-Flex-Algorithm-Pruning-Input dienen.

Claim-to-RFC-Evidenzledger

Aussage RFC-Evidenz
Reverse Affinity, Status, Regeln 8–10 und die Detailsemantik RFC 9917
Flex-Algorithm-Grundmodell, FAD-Auswahl und frühere Pruning-Regeln RFC 9350
Frühere Bandbreiten-, Verzögerungs-, Metrik- und Constraint-Erweiterungen RFC 9843
Extended-Administrative-Group-Format RFC 7308
IS-IS-/OSPF-Verhalten, Längen und Duplikate in den neuen Sub-TLVs RFC 9917, Abschnitte 5–12

Abnahmepfad für Betreiber

  1. Telemetrie und Besitz: Quelle und Besitzer der Eingabefehler dokumentieren; keine automatische Fehlererkennung unterstellen.
  2. Schwellen: Set und Clear getrennt definieren, Hysterese testen und die Werte topologiespezifisch begründen.
  3. Codierung: RFC 7308, Längen, Werte und Duplikate prüfen; IS-IS und OSPF getrennt validieren.
  4. Routinglogik: gewinnenden FAD, Exclude, Include-any, Include-all und die unveränderte Regelreihenfolge nachweisen.
  5. Betrieb: gemischte Unterstützung, Flooding, Rekalkulation, Konvergenz und Observability unter Last prüfen.
  6. Entscheidung: nur mit reproduzierbarer Evidenz aktivieren; bei Abweichung Rollback ausführen und die Ursache festhalten.