Zusammenfassung

  • draft-ietf-idr-fsv2-ip-basic-08 führt User Order, obligatorische beziehungsweise optionale Komponenten und Dependent Filters Chains ein; die Entscheidung bleibt jedoch lokal und bestätigt keine netzweite Installation.
  • Für jedes Ziel braucht der Betrieb einen eigenen Beleg: empfangene Regel, Fähigkeiten, Validierung, wirksame Reihenfolge, Auslassungen, Software- und Hardwarezustand, Zähler, Entfernung und beobachtete Paketwirkung.

Grüne Sessions, verschiedene Datenebenen

Der Controller kündigt einen Notfallfilter an. Route Reflectors verteilen ihn, alle erwarteten Peers empfangen den UPDATE. Die Kontrollfläche meldet Erfolg.

Ein Edge-Gerät installiert Match und Actions vollständig. Ein zweites unterstützt eine obligatorische Komponente nicht und verwirft lokal die gesamte Abhängigkeitsgruppe. Ein drittes lässt eine optionale Komponente weg und installiert den Rest. Ein älteres Gerät propagiert eine neue Action Community, obwohl es ihre Bedeutung nicht kennt.

Das Steuerobjekt ist angekommen, die wirksame Policy ist auseinandergegangen. Revision 08 vom 28. September 2026 beschreibt diese Lage selbst. Ihr klarster Satz lautet: BGP besitzt weiterhin keine Action-Reply-Funktion.

Empfang beweist Transport. Er beweist keine Ausführung.

Ein aktiver Entwurf ist kein Einsatznachweis

Der Datatracker führt Revision 08 als aktiven IDR-Internet-Draft im Zustand I-D Exists. Der Text nennt Standards Track, während das Metadatenfeld zum geplanten RFC-Status leer bleibt. AFI-, SAFI- und Typwerte sind teils TBD; redaktionelle Hinweise und ausgelagerte Action-Arbeit bleiben sichtbar.

Der Entwurf belegt damit ein Standardisierungsproblem, aber keinen Produkteinsatz, keine Betreiberkonfiguration und keinen Vorfall.

RFC 8955, RFC 8956 und RFC 9117 bilden die FSv1-Grundlage. FSv2 nutzt andere Familien, sodass beide Versionen „ships in the night“ koexistieren. Im Übergang unterstützen Peers beide, nur eine oder keine Version.

Pakete treffen auf einem Gerät trotzdem nur auf eine tatsächlich wirksame Reihenfolge.

User Order transportiert Absicht

Jede FSv2-NLRI trägt eine 32-Bit-User-Order; kleinere Werte haben bessere Präzedenz. So kann ein Betreiber die Standardsortierung übersteuern.

Bei einer engen Permit-Regel und einem breiten Drop entscheidet die Reihenfolge über Erreichbarkeit. Der Entwurf empfiehlt FSv2 vor FSv1 und eine gemeinsame lokale Datenbank.

Doch der Empfänger muss lokale Regeln zusammenführen, Gleichstände lösen, Match und Actions validieren und die Darstellung in Software oder Hardware programmieren. BGP liefert die endgültige Reihenfolge nicht an den Ursprung zurück. Angeordnete und installierte Reihenfolge gehören beide in den Beleg.

DFC koordiniert nur lokale Ungültigkeit

Die Dependent Filters Chain verhindert gefährliche Teilinstallation. Das Beispiel kombiniert eine spezifische SMTP-Permit-Regel mit DSCP-Markierung und eine breitere Drop-Regel. Kann ein Gerät DSCP nicht ausführen und installiert nur den Drop, fällt legitimer Verkehr aus.

Ein von null verschiedener DFC-Wert verbindet Regeln. Ist eine lokal ungültig, werden alle Regeln mit demselben DFC auf diesem Gerät ungültig und nicht installiert.

Das ist kein verteilter Commit. Ein anderer Knoten kann die Gruppe akzeptieren; ein Reflector kann nur Syntax prüfen. DFC vergleicht keine Flotte, bestätigt nichts beim Absender und rollt andernorts installierte Regeln nicht zurück.

Der gemeinsame Fate gilt in einer lokalen Entscheidung, nicht netzweit.

Optionalität verändert die effektive Regel

Eine nicht unterstützte obligatorische Match-Komponente macht die Regel ungültig. Eine optionale Komponente darf entfallen, während der Rest als gültig installiert wird.

Das erleichtert Migration, kann aber die Treffermenge erweitern. Verschwindet ein neuer einschränkender Qualifier auf alter Hardware, bleiben Prefix und Action für mehr Pakete wirksam.

Auslassung muss deshalb sichtbar werden: welches Element fehlt, welche Restmenge trifft, welche Action bleibt und wer diese Abweichung autorisierte. Gültig bedeutet nicht identisch.

Bei nicht installierbaren Actions dürfen Implementierungsdefaults oder Konfiguration die Gültigkeit bestimmen. Weitergehende Ordnung und Validität von Actions bleiben Zukunftsarbeit. Eine gemischte Flotte hat damit keinen automatisch gemeinsamen Ausgang.

Bytes können ohne Bedeutung weiterreisen

FSv2 verknüpft Actions über Extended Communities. RFC 4360 regelt Transport und Transitivität. Ein älteres Gerät kann eine unbekannte transitive Action korrekt weitergeben, ohne zu erkennen, dass sie angefordert wurde.

Der Entwurf beschreibt dann Best Effort für bekannte Actions. Eine beabsichtigte Kombination aus Markieren, Sampling und Redirect kann lokal auf eine Teilmenge schrumpfen. Die vollständige Mehrfach-Action-Lösung hängt von späterer Container-Arbeit ab. Eine Community in BGP ist kein Beweis für die Hardwarewirkung.

Validiert, installierbar und installiert

FSv2 prüft NLRI-Struktur, Routeigenschaften und Actions. Standardmäßig hängt Feasibility unter anderem von Destination Prefix und passender Unicast-Route ab; explizite Konfiguration kann Teile lockern.

Nicht begrenzbare Fehlformate können einen Session Reset erfordern. Andere Fehler nutzen treat-as-withdraw nach RFC 7606. Revision 08 warnt, dass ein fehlerhafter Withdraw einer zuvor gültigen NLRI eine stuck route hinterlassen kann und fordert Betreiberbenachrichtigung.

„Nicht mehr advertised“ heißt daher nicht „nicht mehr wirksam“. RIB, Policy Store, Software Classifier, Hardwaretabelle und Paketpfad brauchen getrennte Entfernungsbelege.

Schnelle Verteilung, langsamere Bestätigung

RFC 4760 und Route Reflectors skalieren die Verteilung; Extended Communities tragen Actions. BGP ist schnell, weil es nicht auf Hardwareprogrammierung jedes Ziels wartet.

Der Entwurf schlägt ergänzende Installationsabfragen über NETCONF oder RESTCONF vor. RFC 6241 und RFC 8040 bieten Request/Response, aber kein automatisch einheitliches FSv2-Rezept. Eine Antwort kann Annahme, Datastore-Änderung oder Softwarezustand bedeuten, ohne Hardware und Pakete zu beweisen.

Ein Zwei-Geschwindigkeiten-Modell passt: BGP eröffnet eine begrenzte, befristete Intervention; eine Belegschleife bestätigt pro Ziel Regel, Zähler, Paketwirkung und Entfernung.

Der notwendige Operationsbeleg

Aufzeichnen: Dokumentversion und Identifikatoren; Autorität und Zielmenge; NLRI, User Order, DFC und Flags; Action Communities; Validierungsdaten und Lockerungen; Peer-Zeiten; Fähigkeiten; unbekannte, fehlende und ausgelassene Elemente; DFC-Urteil; kombinierte FSv1/FSv2-Reihenfolge; Software- und Hardwareidentitäten; Zähler oder Samples; Ablauf, Withdraw und beobachtete Löschung; Fortsetzung oder Rollback.

Empfang beweist Transport, Validierung lokale Regelkonformität, ein Tabelleneintrag Programmierung und ein Counter Paketkontakt. Kein Beleg erfindet den nächsten.

Running-Code-Primat bedeutet, die Norm mit dem Zustand zu verbinden, den konkrete Geräte tatsächlich erzeugten.

Quellen