Zusammenfassung

  • Am 5. September 2026 erschien Revision 18 von Traffic Steering using BGP FlowSpec with SR Policy. Zum Prüfstichtag war sie ein Internet-Draft im Zustand AD Evaluation::External Party, kein gebilligter RFC.
  • Revision 17 verlangte normalen Redirect-to-IP-Rückfall, wenn ein Umleitungsziel, aber keine gültige Color vorhanden war. Revision 18 verbietet diesen Rückfall bei erkennbarer, aber unvollständiger SR-Absicht und verlangt Verwerfen oder eine lokale Fehlerpolitik.
  • Eine gültige FlowSpec-Route bleibt in der Loc-RIB und wird weiter angekündigt, auch wenn die SR Policy Down, unauflösbar oder nicht in FIB/TCAM installiert ist. Kontrollstatus und Paketwirkung sind getrennte Tatsachen.
  • Laut aktuellem Kompatibilitätsabschnitt kann ein nicht unterstützender Headend das Prefix-SID-Attribut ignorieren und normales Redirect-to-IP anwenden. In einem gemischten Bestand kann dasselbe Update hier verworfen und dort umgeleitet werden.
  • Der frühere Working Group Last Call bezog sich auf Revision 13. Nach Revision 17 bat der zuständige Area Director die IDR-Chairs um eine neue Konsensabfrage. Sie muss festhalten, welche Revision und welche Fehlerzweige Zustimmung erhalten.

Aus einer Lücke wurde eine Sperre

FlowSpec verteilt über BGP Regeln, die Pakete auswählen und eine Aktion zuweisen. Der Entwurf verbindet diese Regeln mit Segment Routing: Redirect-to-IP liefert das Ziel, eine Color Extended Community die zweite Hälfte des (Endpoint, Color)-Schlüssels für eine SR Policy. In einem SRv6-Modus kann ein Prefix-SID-Attribut zusätzlich einen Egress Service SID für eine bestimmte Aktion am Ziel tragen.

Damit entstehen drei ähnliche, aber nicht gleiche Nachrichten. Reines Redirect-to-IP ohne SR-Signal bleibt eine gewöhnliche IP-Umleitung. Ziel plus gültige Color wählt eine SR Policy. Ein Prefix-SID neben dem Ziel, aber ohne gültige Color, zeigt dagegen eine unvollständige SR-Absicht: Der gewünschte Dienst ist erkennbar, die Policy aber nicht eindeutig auswählbar.

Revision 17 löste diesen Fall permissiv. Sie ignorierte Prefix-SID für SR und fiel auf Redirect-to-IP zurück. Revision 18 dreht die Entscheidung um. Ein unterstützender Headend darf weder eine Default- oder Null-Color-Policy suchen noch den Service-SID verwenden oder die Nachricht als einfache Umleitung lesen. Passender Verkehr wird verworfen oder nach lokaler Fehlerpolitik behandelt.

Das ist kein pauschales „ohne Color immer Drop“. Eine echte, alleinstehende Redirect-to-IP-Anweisung bleibt gültig. Gesperrt wird die Umdeutung einer halben SR-Anweisung. Damit soll ein unbemerkter Weg außerhalb der beabsichtigten Policy vermieden werden; der Preis kann eine sichtbare Unterbrechung sein.

Das Update lebt länger als seine FIB-Aktion

Wenn die zugehörige SR Policy ausfällt, nicht aufgelöst oder nicht programmiert werden kann, bleibt eine BGP-seitig gültige FlowSpec-Route in der Loc-RIB. Sie wird weiterhin nach den üblichen Regeln an nachgelagerte Peers angekündigt. Der Zustand des Underlays oder der Policy entwertet nicht automatisch die Instruktion.

Im Forwarding gilt das Gegenteil. Die Steering-Aktion darf nicht aktiviert oder muss als inaktiv markiert werden. Auch ein unerreichbarer Egress Service SID darf keinen stillen Rückfall auf den kürzesten IP-Pfad auslösen. Als lokale Standardreaktion empfiehlt der Entwurf Verwerfen, lässt aber eine anders definierte Betreiberpolitik zu. Gültige Nicht-Steering-Aktionen wie Rate-Limits bleiben wirksam.

Diese Trennung erleichtert die Erholung: Kehrt die Policy zurück, muss die Route nicht neu gelernt werden. Sie macht aber einen grünen RIB-Eintrag zu einem unvollständigen Beleg. Abnahme und Incident-Analyse müssen Route angenommen, Route weitergegeben, FIB installiert und Paket beobachtet getrennt führen.

Revision 18 fordert Fehlergründe, Managementmeldungen und Drop-Zähler. Bei Update-Fluten oder Ressourcenknappheit dürfen Einzelmeldungen limitiert, zusammengefasst oder vorübergehend unterdrückt werden. Das schützt den Kontrollprozess, nimmt der Stille aber ihre Beweiskraft. Unterdrückungsstatus und aggregierter Nenner gehören zum Alarm.

Ein Legacy-Headend nimmt die andere Abzweigung

Ein Gerät kann Basis-FlowSpec und Redirect-to-IP unterstützen, ohne den neuen Entwurf zu kennen. Prefix-SID ist optional transitiv. Der Headend kann es unverändert weitergeben, für seine eigene Weiterleitung ignorieren und auf die bekannte Redirect-to-IP-Aktion zurückfallen.

Die Bytes bleiben also gleich, ihre Wirkung nicht. Das Revision-18-Gerät erkennt die unvollständige SR-Absicht und verweigert die Umleitung. Das ältere Gerät kennt diesen semantischen Zustand nicht und sieht eine gültige Umleitungsanweisung. Dafür braucht es weder einen Parsingfehler noch eine gestörte BGP-Sitzung, nur eine unbekannte Fähigkeitsgrenze.

Der Entwurf verlangt administrative Schalter pro Nachbar und Dienst sowie Filter an Vertrauensgrenzen. Diese Vorkehrungen begrenzen die Verteilung, erkennen aber nicht selbst die implementierte Revision. Der Sender benötigt eine belastbare Empfänger- und Feature-Liste; gemischte Gruppen dürfen erst nach einem expliziten Test dieselben Attribute erhalten.

Der entscheidende Test erzwingt die Fehler: reines Redirect-to-IP, gültiger Mode 1 und 2, fehlende oder beschädigte Color, ausgefallene Policy, unerreichbarer SID, erschöpfte FIB und nicht unterstützender Empfänger. Jede Zeile muss Loc-RIB, Weitergabe, FIB, Drop- oder Redirect-Zähler, Testpaket, Meldung, Unterdrückung und Wiederherstellung zeigen.

Revision 13 kann Revision 18 nicht bevollmächtigen

Der Shepherd-Bericht beschreibt einen kurzen, einwöchigen WGLC zu Revision 13 mit positiver Unterstützung. In der anschließenden AD-Prüfung kamen zwei Betriebsmodi, eine sequentielle Attributauswertung, weitere Service-Aktionen, Fehlerregeln, Koexistenz und deutlich mehr Betriebs- und Sicherheitstext hinzu.

Am 26. August, nach Revision 17, bat der zuständige Area Director die IDR-Chairs, vor einem weiteren Schritt erneut den Konsens der Gruppe zu prüfen. Der Datatracker wechselte zu AD Evaluation::External Party. Revision 18 vom 5. September änderte wiederum die materielle Schadensentscheidung: kein normaler Rückfall bei unvollständiger Absicht, ein eigener Fall für unerreichbare Service-SIDs und detailliertere Segment-, Filter- und Beobachtungsregeln.

Die neue Abfrage ist keine leere Wiederholung. Man kann das Ziel der SR-Steuerung befürworten und den gewählten Fail-closed-Zweig ablehnen. Für einen Sicherheitsdienst kann eine ungeplante Umleitung schlimmer sein; für einen Verfügbarkeitsdienst ein vermeidbarer Drop. Rough Consensus soll zeigen, dass technische Einwände verstanden und behandelt wurden. Er wird nicht von einer früheren Tabelle vererbt, die das Gegenteil verlangte.

Die Frage sollte deshalb Revision 18 und ihre konkreten Entscheidungen nennen: unvollständige Color, RIB-Erhalt, Policy- und SID-Ausfall, lokale Fehlerregel und Legacy-Verhalten. Der Abschluss muss Einwände und die Begründung der Chairs mit dem Ergebnis erhalten.

Running Code hat ein Datum

Der Implementation-Status nennt vier Router und vier Controller, die zwischen Juli und Oktober 2021 an von China Mobile organisierten Interoperabilitätstests teilnahmen. Außerdem meldet er Produktionseinsatz im Backbone seit August 2022. Zugleich sagt der Pflicht-Hinweis, dass die Angaben von Beitragenden stammen, nicht unabhängig geprüft wurden und keine IETF-Billigung darstellen.

Die Chronologie begrenzt die Aussage. Keine geprüfte Quelle verbindet die Tests von 2021 mit der heutigen Fehler-Matrix, dem unerreichbaren Service-SID, der Replace-or-Append-Regel oder einem gemischten Bestand. Ein späterer Satz ergänzt keinen früheren Testfall.

Die alte Erfahrung bleibt wertvoll, wenn sie versioniert wird. Pro Implementierung gehören Build, Draft-Revision, aktivierte Funktion, negative Kombination, Peer-Fähigkeit und beobachtetes Paket in den Bericht. Ein aktueller Wiederholungstest kann das historische Ergebnis erweitern, ohne dessen Reichweite zu überdehnen.

Ein versionsgebundener Entscheidungsbeleg

Der Konsensteil hält Quellhash von Revision 18, Zeitraum, genaue Frage, Antwortarchiv, Einwände und Bewertung der Chairs fest. Der Interopteil verwendet dieselbe Revision und listet einfache Umleitung, gültige Modi, ungültige Color, Policy Down, SID unerreichbar und FIB-Fehler.

Für jede Zeile stehen unterstützender und nicht unterstützender Headend getrennt. Route angenommen, weiter angekündigt, Aktion installiert und Paketwirkung sind eigene Felder. Zähler, Alarm und Log-Unterdrückung schließen die Lücke.

Der Rolloutteil nennt Sender, Empfängergruppen, Revisionen, Filter, erlaubte SID-Bereiche, lokale Fehlerpolitik, Retry, Canary und Rückfallauslöser. Sensible Adressen dürfen pseudonymisiert werden; Version und Ergebnis nicht. Korrekturen werden angehängt, statt einen ersten Fehlschlag zu überschreiben.

Heng Lus Disziplin der minimalen Spezifikation dient hier nur als redaktioneller Maßstab. Der gemeinsame Kern muss klein, deterministisch und prüfbar sein. Die lokale Verlustentscheidung kann beim Betreiber bleiben, sofern Befugnis und Wirkung sichtbar sind. Weder ein IETF-Label noch lokale Freiheit legitimieren eine verborgene Versionsgrenze.

Revision 18 mag die bessere Entscheidung enthalten. Sie muss dennoch Zustimmung für die heutige Regel erhalten und in neuen wie alten Headends geprüft werden. Der Konsens von Revision 13 und Tests aus 2021 können diese Aufgabe nicht stellvertretend erfüllen.

Quellen

  1. IETF Datatracker — Traffic Steering using BGP FlowSpec with SR Policy
  2. IETF — Text von Revision 18
  3. IETF — Text von Revision 17
  4. IETF Author Tools — Vergleich Revision 17 zu 18
  5. IETF Datatracker — Dokumentverlauf
  6. IDR-Liste — Bitte um erneute Konsensprüfung
  7. IETF — Document Shepherd Write-up
  8. RFC 8955 — Dissemination of Flow Specification Rules
  9. RFC 9256 — Segment Routing Policy Architecture
  10. RFC 7942 — Improving Awareness of Running Code
  11. RFC 7282 — On Consensus and Humming in the IETF
  12. Heng Lu — Minimum Initial Specification