Zusammenfassung

  • RFC 9573 ersetzt viele eingangsspezifische Labelräume durch einen domainweiten gemeinsamen Block oder wenige gemeinsame kontextspezifische Räume.
  • Die Skalierung setzt voraus, dass alle PEs und Segmentierungspunkte das Verfahren beherrschen und dieselbe Zuordnung kennen; wie das sichergestellt wird, bleibt außerhalb des Dokuments.
  • Belastbare Einführung verlangt eigene Belege für Zuteilung, Generation, Reservierung, Tabellenauswahl, FIB-Installation, Routenkonsistenz und beobachtete Mandantenzustellung.

Der Gewinn stand in der Tabelle, die Voraussetzung nicht

Eine Kapazitätsrechnung zeigt eine Million eingangsspezifischer Labelinterpretationen. Daneben steht die optimierte Zahl: tausend gemeinsame Zuordnungen. Der Business Case scheint abgeschlossen, bevor die erste Konfiguration erzeugt wurde.

RFC 9573 liefert genau dieses Größenbeispiel. Bei 1.001 PEs mit jeweils 1.000 VPNs oder Broadcast Domains muss jedes Ausgangs-PE im ursprünglichen Modell eine Million Werte in tausend Kontexten verstehen. Eine zentrale Stelle kann jedem Dienst ein gemeinsames Label geben und den Zustand drastisch verkleinern.

Doch die Rechnung verschiebt eine Voraussetzung aus der Datentabelle in die Organisation: Alle Teilnehmer müssen dieselbe Bedeutung installiert haben. Das Label trägt keinen Ausstellerkontext mehr, der abweichende Belegungen natürlich trennt.

Der Standard verlangt Vollständigkeit, kann sie aber nicht beobachten

Alle PE-Router und Segmentierungspunkte müssen das Verfahren unterstützen. RFC 9573 sagt zugleich, dass die Sicherstellung dieser Bedingung außerhalb seines Geltungsbereichs liegt. Auch die gemeinsame Zuteilung und ihre Bekanntheit bei jedem Mitglied werden durch externe Methoden hergestellt.

Das DCB-Bit ist daher kein Konvergenznachweis. Es erklärt, aus welcher Art Labelraum der Wert stammen soll. Es beweist weder eine reservierte Domain-wide Common Block-Spanne auf jedem Gerät noch dieselbe aktive Konfigurationsgeneration oder einen Eintrag im Datenpfad.

Der reale Domainumfang muss inventarisiert werden. Ein loses Architekturdiagramm reicht nicht, denn das RFC definiert die Domain pragmatisch als die Routermenge, die denselben DCB teilt.

Der äußere Wert wählt die Tabelle, nicht ihre Wahrheit

Ist ein großer gemeinsamer Block unpraktisch, kann ein kleiner DCB-Wert einen gemeinsamen kontextspezifischen Labelraum kennzeichnen. Das Dienstlabel liegt darunter. Der Empfänger liest außen, welche Tabelle gilt, und innen, welcher Dienst gemeint ist.

Damit entstehen zwei installierbare Bindungen. Der Selektor gehört in die Standard-MPLS-Tabelle; der Dienstwert gehört in die gewählte Kontexttabelle. Ein korrekter Selektor vor einer veralteten Tabelle führt zuverlässig zum falschen Ergebnis.

Die Context-Specific Label Space ID Extended Community macht den Namensraum sichtbar. Sie enthält aber keine Freigabe, keine Controllerrevision und keine ASIC-Quittung. Ein Audit muss Sollzustand, Gerätekonfiguration, tatsächliche Tabellen und beobachtete Testpakete zusammenführen.

Segmentierung braucht wieder lokale Eindeutigkeit

In einer Region können zwei Flüsse denselben selektiven Tunnel nutzen. Hinter einem Segmentierungspunkt laufen sie möglicherweise über verschiedene Tunnel weiter. Der Grenzknoten muss sie auseinanderhalten, ohne zwingend IP- oder MAC-Lookups in einer VRF auszuführen.

Dafür erhält jedes PE einen disjunkten Block in wenigen gemeinsamen Kontexten und vergibt daraus Labels für segmentierte PMSIs. Die zentrale Stelle verteilt nicht jeden Einzelwert, bleibt aber für überschneidungsfreie Blockgrenzen und Eigentumsepochen verantwortlich.

Die VRF-Alternative verschiebt das Wachstum zu (C-S,C-G)-Routen. Weniger Labels bedeuten dann mehr Flowzustand am Segmentierungspunkt. Entscheidend ist nicht die kleinste Zahl in einer Folie, sondern welcher Zustand ausfällt, wer ihn lesen kann und wie er zurückgenommen wird.

Widerspruch wird zurückgezogen

DCB-Flag und Context-Specific Label Space ID EC dürfen nicht gemeinsam auftreten. Eine Route mit beiden wird als withdrawn behandelt. Fehlen beide, gilt weiterhin die eingangsspezifische Upstream-Interpretation.

Auch mehrere x-PMSI/IMET-Routen desselben Tunnels müssen dasselbe Interpretationsregime verwenden. Eine Mischung lässt offen, in welcher Tabelle das nächste Label zu lesen ist. Der Empfänger verwirft die Routenlogik, statt zu raten.

Das ist ein guter Fail-Closed-Punkt. Er beweist jedoch nicht, dass alte FIB-Einträge sofort verschwunden sind oder kein Paket mehr unter der früheren Zuordnung unterwegs ist. Datenpfadruhe und Wiederverwendung brauchen zusätzliche Belege.

IANA registriert Felder, nicht Betriebszustände

Das DCB-Bit, der Extended-Community-Subtyp und das Register für Label-Space-ID-Typen schaffen gemeinsame Syntax. Sie belegen keine Implementierung, Aktivierung oder fehlerfreie Zuteilung.

RFC 9573 sieht gegenüber seinen Grundlagen keine neuen Sicherheitsbedenken. Aus der Koordinationsabhängigkeit folgt deshalb kein behaupteter Angriff. Die belegbare Aussage bleibt: Die gemeinsame Semantik entsteht außerhalb des Pakets und muss im Betrieb nachgewiesen werden.

Sources

Quellen