Zusammenfassung

  • RFC 9819 aktualisiert RFC 9252, weil ein bitweises ODER den beabsichtigten End.DT2M Service SID nur dann korrekt bildet, wenn die Ethernet-A-D- und Inclusive-Multicast-Ankündigungen dieselbe SID-Struktur verwenden.
  • Beim ESI Filtering liefert die Inclusive Multicast Route LOC:FUNC und die Einfügegrenze; die Ethernet A-D per ES Route liefert Arg.FE2. Gleiche, von null verschiedene Argumentlängen sind erforderlich, aber gleiche Länge bedeutet nicht gleiche Gesamtstruktur.
  • Empfang und Parsing beider Routen sind Kontroll­ebenenbelege. Sie beweisen weder eine aktuelle Zuordnung noch lokale Auswahl, FIB- oder Local-SID-Programmierung, die Ausführung des Split-Horizon-Filters oder eine korrekte BUM-Zustellung.

Das verlockende Incident-Ticket lautet: Beide Routen vorhanden, Attribut gültig, SID berechnet. Fall geschlossen. Die entscheidende Frage ist präziser: Nach wessen Struktur wurde gerechnet?

RFC 9252 beschrieb ursprünglich, wie ein Ingress-PE das ESI Filtering Argument aus einer EVPN Ethernet Auto-Discovery per Ethernet Segment Route mit dem passenden End.DT2M SID einer Inclusive Multicast Ethernet Tag Route durch bitweises ODER verbindet. Das funktioniert, wenn die beiden Beiträge ihre bedeutsamen Bits an denselben Positionen tragen. RFC 9819, veröffentlicht im Juli 2025, hält fest, dass Implementierung und Interoperabilität eine Mehrdeutigkeit aufgedeckt haben: Eine einheitliche Struktur ist keine universelle Eigenschaft.

Die Änderung ist im Paketformat klein, für die Beweiskette aber groß. Zwei syntaktisch gültige BGP-Objekte werden nicht schon deshalb zu einer gültigen Weiterleitungsanweisung, weil sich ihre 128-Bit-Werte kombinieren lassen. Der Empfänger muss wissen, welche Ankündigung das Layout des Service SID besitzt, ob ein Argument zulässig ist, wie viele Bits es umfasst, wo es beginnt und welche Service-Zuordnung seine Verwendung rechtfertigt.

Ein SID, zwei Quellen der Bedeutung

RFC 8986 zerlegt einen SRv6 SID in Locator, Function und ein optionales Argument. End.DT2M entkapselt einen Ethernet-Frame und flutet ihn über eine L2-Tabelle. Sein Arg.FE2 bildet lokal auf einen Ethernet Segment Identifier ab, damit der Disposition PE die betreffenden Ausgangsschnittstellen ausschließt und Split Horizon wahrt.

RFC 9819 trennt dafür die Beiträge. Die Inclusive Multicast Ethernet Tag Route, EVPN Route Type 3, kündigt den LOC:FUNC-Teil von End.DT2M für eine Broadcast Domain an. Die Ethernet A-D per ES Route, Route Type 1, kündigt das ESI-Filtering-Argument an. Da das Verhalten ein Argument unterstützt, führen beide ein SRv6 SID Structure Sub-Sub-TLV.

Diese Struktur ist keine Dekoration. Locator Block Length, Locator Node Length und Function Length bestimmen den Offset, an dem das Argument beginnt; Argument Length bestimmt dessen zulässige Größe. Der Endpunkt, dem LOC:FUNC gehört, kündigt diese Struktur an. Die SR-Quelle setzt daraus den vollständigen LOC:FUNC:ARG-Wert als IPv6-Ziel oder SRH-Segment zusammen.

Damit löst RFC 9819 einen konkreten Fehler. Im Beispiel mit mehreren Broadcast Domains ist das Argument jeweils 16 Bit lang, während ein Type-3-Service-SID eine Function Length von 32 Bit und ein anderer 16 Bit verwendet. Dasselbe Argument muss folglich an verschiedenen Offsets stehen. Ein blindes ODER ist nicht neutral; es unterstellt stillschweigend, dass die Offsets bereits übereinstimmen.

Der Entscheidungsbaum ist aussagekräftiger als ein grüner Parser

Meldet Type 3 AL=0, erwartet dieser Service SID kein ESI-Filtering-Argument. Der Ingress baut LOC:FUNC mit nachfolgenden Nullbits und ignoriert SID-Wert und Struktur aus Type 1. Ein Parser kann ein Argument anzeigen, das die Weiterleitungslogik gerade nicht verwenden darf.

Meldet Type 3 eine AL ungleich null, sucht der Ingress die passende Ethernet A-D per ES Route und prüft End.DT2M. Fehlt die Route oder meldet Type 1 AL=0, gibt es kein nutzbares Argument; der Ingress fällt auf LOC:FUNC zurück und sollte protokollieren, wenn Filtering erwartet wurde.

Sind beide AL-Werte ungleich null, aber verschieden, liegt ein Konfigurationsfehler vor. Das Argument ist unbrauchbar, und BUM-Verkehr von diesem Ethernet Segment darf wegen Schleifengefahr nicht weitergeleitet werden. Sind die Werte gleich, fügt der Ingress das Type-1-Argument an dem durch die Type-3-Struktur bestimmten Offset ein und setzt alle Bits hinter dem deklarierten SID auf null.

Gleiche AL ist damit eine Eingangskontrolle, kein allgemeines Kompatibilitätszertifikat. Sie belegt, dass die Nutzlast in das vom Eigentümer angekündigte Argumentfeld passt. Sie belegt weder identische Gesamt­layouts noch die Zugehörigkeit des Type-1-Datensatzes zum beabsichtigten Ethernet Segment oder die Installation der resultierenden Adresse am Endpunkt.

Identität und Zeit kommen vor der Komposition

RFC 7432 liefert den EVPN-Kontext der beiden Routentypen: Route Distinguisher, Route Target, Ethernet Tag, ESI, originierende PEs und Withdrawals. Diese Felder verhindern, dass ein frisches LOC:FUNC mit einem Argument aus einem anderen Segment, einer anderen Broadcast Domain oder einer früheren Pfadgeneration verbunden wird.

Ein brauchbarer Konstruktionsbeleg benennt deshalb beide empfangenen Pfade und ihre Zuordnung. „Type 1 und Type 3 vorhanden“ ist zu schwach. Er sollte Originator, EVI, Ethernet Segment, ausgewählte Pfade, Beobachtungszeitpunkt, Withdrawals und End.DT2M-Variante festhalten. Routenempfang beweist keine Aktualität; eine aktuelle RIB-Sicht beweist nicht, dass jeder Cache und jedes programmierte Objekt dieselbe Generation verbraucht hat.

RFC 9800 definiert komprimierte SID-Listen. RFC 9819 erlaubt komprimierte und unkomprimierte End.DT2M-Varianten in den betreffenden Ankündigungen, wenn die AL-Prüfungen bestehen. Es erlaubt nicht, Variante oder Struktur aus dem Nachweis zu löschen. Auch das Transposition Scheme von RFC 9252 bleibt unverändert: Werden variable Bits in einem MPLS-Label-Feld transportiert, bleiben Offset, Länge und Feldgrenzen eigenständige Prüfgrößen.

Der konstruierte SID endet vor dem Netzwerkergebnis

RFC 9819 spezifiziert Signalisierung, Konsistenzprüfungen und Konstruktion. Es behauptet nicht, dass eine korrekte Berechnung durch Policy ausgewählt, in Hardware geschrieben oder von einem Paket ausgeführt wurde. Dafür gelten spätere Autoritäten.

Der Ingress muss unterstütztes Verhalten, Feature-Version, gewählte Konstruktionsmethode, Pfadauswahl und programmierten 128-Bit-Wert nachweisen. Der Egress muss zeigen, dass der entsprechende Local SID die beabsichtigte End.DT2M-Variante, L2-Tabelle und aktuelle Arg.FE2-Abbildung aufruft. Erst Paketbelege zeigen Entkapselung und den Ausschluss der richtigen Schnittstellen. Selbst dann muss die Ergebnisebene noch korrekte Empfänger, ausbleibende Rückkopien sowie das Fehlen von Duplikaten und Schleifen im selben Zeitfenster bestätigen.

Das grenzt benachbarte Arbeiten sauber ab. RFC 9819 behandelt weder die BGP-zu-SR-Policy-Manager-Auswahl aus RFC 9830, noch PCEP-Color-Semantik aus RFC 9863, interdomain D-PATH aus RFC 10039 oder P2MP-Baum- und Leaf-Lebenszyklen aus RFC 10018. Es behandelt den engeren Moment davor: Dürfen zwei angekündigte Komponenten zum beabsichtigten Service SID werden, ohne eine gemeinsame Struktur zu erfinden?

Heng Lus Minimum Initial Specification liefert dafür eine redaktionelle Disziplin: Die gemeinsame Regel bleibt deterministisch und lokal überprüfbar, spätere Betriebsentscheidungen bleiben bei den Teilnehmern. Running-Code Primacy markiert die Grenze zwischen Veröffentlichung und Betrieb; Reality Layers warnt davor, symbolische Zustimmung mit physischer Wirkung zu verwechseln. Das ist der analytische Rahmen des Autors, keine Aussage über die Absicht der IETF.

Die belastbare Kette hat acht Belege: Routenidentität und Aktualität; Verhalten und Struktur; Zuordnung über beide Routen; exakte Konstruktion; lokale Annahme und Auswahl; programmierter Ingress- und Egress-Zustand; Paketausführung; beobachtetes Service-Ergebnis. RFC 9819 erschwert es, die Mitte dieser Kette mit einer Bitoperation vorzutäuschen. Es macht aus der Kette kein einziges grünes Licht.

Quellen