Zusammenfassung

  • Die vom IESG gebilligte Erweiterung lässt einen Kandidatenpfad einer BGP SR Policy die Control-Plane-NRP-ID seiner vorgesehenen Network Resource Partition tragen.
  • Die Zahl beschreibt eine Zuordnung innerhalb einer Domäne. Sie weist keine Ressourcen zu und belegt weder lokales Mapping noch Kapazität, Isolation oder Dienstergebnis.

Zwei Kandidaten, zwei Ressourcenabsichten

Ein Headend lernt zwei Kandidatenpfade mit gleicher Farbe und gleichem Endpoint. Der eine trägt NRP ID 17, der andere 29. Im Control Plane weist die Differenz die Pfade unterschiedlichen Partitionen der Underlay-Ressourcen zu.

Die Nachricht enthält jedoch weder verfügbare Kapazität noch Queue-Zustand, Interface-Konfiguration oder gemessene Isolation. Sie zeigt nicht, ob das Headend den Kandidaten auswählte, die Segmentliste installierte, die ID in den vorgesehenen Data-Plane-Selektor übersetzte und den Dienst tatsächlich dorthin lenkte.

Das ist ein konstruiertes Kontrollbeispiel, kein gemeldeter Vorfall. Es trennt die Autorität der Nachricht von der Autorität der ausführenden Systeme: BGP kann die beabsichtigte Zuordnung transportieren, aber keine Ressource erzeugen.

Am 25. August 2026 um 18:03 UTC meldete die IETF die IESG-Genehmigung von Revision 13 der „BGP SR Policy Extensions for Network Resource Partition“ als Proposed Standard. Die Genehmigung ist ein Standardisierungsereignis, kein Beleg für fertige Register oder Produktionsbetrieb.

Zwischen Genehmigung und RFC bleiben offene Zustände

Der Entwurf stammt aus der Arbeitsgruppe Inter-Domain Routing. Die Ankündigung dokumentiert eine Debatte über Abhängigkeiten von TEAS- und SPRING-Arbeiten, groben Konsens für das Weitergehen und die Entscheidung, normative Referenzen in der Warteschlange des RFC Editor aufzulösen.

Zum Evidenzstichtag 28. August führte der Datatracker Revision 13 noch als Active Internet-Draft. Beim RFC Editor war sie wegen einer fehlenden Referenz blockiert. Die IANA-Prüfung verlangte nach der Versionsänderung eine erneute Durchsicht; die Aktion lief noch. Eine endgültige RFC-Nummer oder abgeschlossene Registrierung wäre daher eine unzulässige Vorwegnahme.

Die Ankündigung nennt zwei Implementierungen. Der öffentliche IDR-Bericht verweist auf Huawei VRP und H3C Comware, enthält aber Text zu einer älteren Fassung und Funktionsfelder mit TBD. Das belegt Entwicklungsarbeit und technische Machbarkeit, nicht vollständige Konformität mit Revision 13, Interoperabilität im Maßstab oder breite Aktivierung.

Die Partition besteht aus Ressourcen und Regeln

RFC 9543 definiert eine Network Resource Partition als Teilmenge von Underlay-Ressourcen samt zugehörigen Richtlinien, die einen oder mehrere Network-Slice-Dienste unterstützen kann. RFC 9732 ordnet sie einem Enhanced-VPN-Rahmen zu, in dem Konnektivitätskonstrukte auf solche Ressourcen abgebildet werden.

Die Partition wird erst durch Betrieb real. Kapazität und Forwarding-Behandlung müssen provisioniert, ihre Nutzung gesteuert, Dienste hineingelenkt und Ergebnisse gemessen werden. Die NRP ID ist kein Ersatz für diese Arbeit.

Revision 13 verwendet eine 32-Bit-Control-Plane-ID, die innerhalb einer NRP-Domäne eindeutig ist. Lokale Konfiguration und Implementierung verbinden sie mit dem NRP Selector ID im Data Plane. Die Zahl ist weder global eindeutig noch eine Zusage über einen Ressourcenbestand.

Auch der Anwendungsbereich ist begrenzt: Er umfasst ein Design mit einem dedizierten, domänenweit gültigen Data-Plane-Selektor. Andere NRP-Auswahlverfahren können ohne explizites Signal in SR Policy auskommen und liegen außerhalb des Dokuments.

Sechs Oktette schaffen eine Drahtregel

Die Erweiterung definiert ein NRP-ID-Sub-TLV im BGP Tunnel Encapsulation Attribute, wenn der Tunneltyp SR Policy ist. Revision 13 nutzt Typ 123. Die Länge muss sechs Oktette betragen: je eines für Flags und Reserved sowie vier für die ID.

Flags und reservierte Bits werden als null gesendet und beim Empfang ignoriert. NRP ID null ist reserviert; Sender dürfen sie nicht verwenden, Empfänger ignorieren ein Sub-TLV mit diesem Wert. Das Element ist optional und darf pro Kandidatenpfad höchstens einmal vorkommen.

Eine andere Länge oder ein Duplikat macht die NRP-Information zum SR Policy NLRI fehlerhaft. Der Empfänger wendet nach RFC 7606 treat-as-withdraw an. Damit erhält keine strukturell mehrdeutige Behauptung Routing-Autorität.

Ein semantisch falsches, aber korrekt codiertes Mapping bleibt davon unberührt. Die Form kann gültig sein, obwohl die ID lokal auf den falschen Selektor und damit auf andere Ressourcen zeigt.

BGP-Auswahl ist nur die erste Beförderung

Wird ein Kandidatenpfad in einer NRP mit dediziertem Selektor erzeugt, muss der Originator das Sub-TLV aufnehmen. Der empfangende BGP Speaker prüft Gültigkeit und Nutzbarkeit nach RFC 9830. Der normale Best-Route-Algorithmus bleibt unverändert.

Ausgewählte beste Routen der SR Policy SAFI gehen danach an das SR Policy Module. Diese Übergabe markiert eine weitere Zuständigkeit. Eine akzeptierte Route muss nicht zum aktiven Kandidaten werden; ein an SRPM übergebener Pfad kann bei der Installation scheitern; ein installierter Pfad kann wegen Mapping-Drift den falschen Selektor tragen.

Der Beweisweg führt weiter über Kandidatenauswahl, Segmentliste, Version des ID-Selektor-Mappings, Paketmarkierung, Service Steering, provisionierte Queues und Links sowie gemessene Latenz, Verlust, Durchsatz und Isolation. Eine erfolgreiche Anzeige des Controllers belegt nur, dass eine Zuordnung unter bekannten Sitzungsbedingungen gesendet und akzeptiert wurde.

Failover darf nicht unbemerkt die Partition wechseln

Revision 13 erlaubt unterschiedliche NRPs für Kandidatenpfade derselben SR Policy, bezeichnet die Konfiguration aber als gültig und nicht empfohlen. Im Normalfall sollen alle Kandidaten dieselbe NRP-Zuordnung bewahren.

Bei Ausfall oder Präferenzwechsel kann ein anderer Kandidat aktiv werden, während der Dienst denselben Policy-Schlüssel sieht. Wählt der neue Pfad eine andere Partition, ändern sich womöglich zugleich Isolation, Kapazität, Kosten und Offenlegung sensibler Netzabsicht.

Auch dieselbe Zahl auf allen Geräten reicht nicht. Headends müssen sie gleich interpretieren, der Data Plane muss den gleichen Selektor anwenden, und das Underlay muss die zugehörigen Ressourcen bereitstellen. Einheitliche Zahlen über abweichenden lokalen Maps sind koordinierte Syntax ohne koordiniertes Verhalten.

Der zusätzliche Zustand liegt an Controller und Headend

Mit der Zahl der NRPs können laut Entwurf auch SR Policies und Kandidatenpfade wachsen. Die zwischen Controller und Headends ausgetauschte Information kann proportional zunehmen.

Verfahren für SR-Policy-Anzeigen und BGP-Best-Path ändern sich nicht. Nur die betreffenden Headends installieren die Kandidaten; Transitknoten erhalten dadurch nicht denselben zusätzlichen Zustand. Diese Grenze ist wichtig, aber kein Nullkostenversprechen.

Controller müssen Zustand erzeugen und abgleichen, Headends müssen ihn empfangen, validieren, weiterreichen und installieren. Monitoring sollte Anzeigen, gültige Routen, beste Routen, SRPM-Kandidaten, aktive Pfade und installierte Selektoren getrennt zählen, sonst verbirgt ein grünes Control Plane den Engpass.

Ein vertrauenswürdiger Peer kann falsch zuordnen

Der Sicherheitsabschnitt übernimmt Schutzmechanismen von BGP, SR Policy und NRP und benennt das lokale Risiko: Eine falsche Zuordnung kann Verkehrsisolation und Ressourcengarantien beeinträchtigen.

Ein authentisierter Controller kann die falsche ID senden. Ein vertrauenswürdiges Headend kann die richtige ID dem falschen Selektor zuordnen. Ein korrekter Selektor kann auf veraltete Ressourcenkonfiguration treffen. Autorisierte Komponenten können gemeinsam ein nicht autorisiertes Ergebnis erzeugen.

Die Anzeige kann außerdem sensible Netzabsicht verraten, etwa Strukturen für missionskritische oder wirtschaftlich bedeutsame Dienste. Betreiber müssen Sender und Empfänger auf vertrauenswürdige Router und Controller-Anwendungen beschränken und die Zuordnung selbst prüfen.

Für jeden Vorgang sollten Controller- und Peer-Identität, NLRI-Schlüssel, Ursprung und Präferenz des Kandidaten, rohe Sub-TLV-Bytes, Validierungs- und Auswahlentscheidung, SRPM-Eingang und -Auswahl, installierte Segmentliste, Mapping samt Version, Ressourcenkonfiguration, Service Steering, beobachteter Paketselektor, Queue-, Verlust-, Latenz- und Isolationsergebnis, Rücknahme, Fallback, Rollback und verbindende Zeitstempel erhalten bleiben.

Quellen