Zusammenfassung

  • RFC 9830 standardisiert die BGP-Übermittlung von SR-Policy-Kandidaten; die semantische Prüfung, die aktive Auswahl und die Installation bleiben Aufgaben des SRPM am Headend.
  • Ein Distinguisher hält Anzeigen auseinander, besitzt laut Standard aber keinen semantischen Wert und belegt weder Rang noch Version oder Autorisierung.
  • Belastbare Evidenz trennt Empfang, BGP-Best-Path, Route-Target-Import, SRPM-Eignung, aktive Auswahl, Binding SID, FIB-Installation und beobachteten Paketpfad.

Auf einem Router laufen zwei verschiedene Wahlen

Das Eingangsszenario ist ein Gedankenexperiment, keine Behauptung über einen bestimmten Hersteller. Ein korrekt codiertes UPDATE kann am Peer eintreffen, die BGP-Strukturprüfung bestehen und als beste Route für sein NLRI ausgewählt werden. Alle drei Ereignisse sind real. Keines beantwortet, welche Segmentliste gerade Pakete führt.

RFC 9830 zieht die Zuständigkeitsgrenze ungewöhnlich deutlich. BGP erzeugt und verbreitet Candidate Paths. Am Headend werden die Informationen an das Segment Routing Policy Module, kurz SRPM, weitergereicht. Dieses Modul kann zugleich Kandidaten aus CLI, NETCONF, PCEP oder lokaler Konfiguration besitzen. Es prüft deren SR-spezifische Semantik, bildet die Kandidatenmenge, wählt einen aktiven Pfad, ordnet eine Binding SID zu und veranlasst die Programmierung des Datenpfads.

Die erste Wahl gehört BGP: Für ein bestimmtes NLRI wird nach BGP-Regeln eine Route bevorzugt. Die zweite gehört dem SRPM: Für eine durch Color und Endpoint identifizierte Policy wird unter allen geeigneten Quellen ein aktiver Kandidat gewählt. Ein BGP-Sieger kann daher gegen einen lokal konfigurierten Kandidaten verlieren. Er kann auch nach der Übergabe an einer Segmentprüfung oder an einer unbrauchbaren Binding SID scheitern.

Ein Dashboard, das „BGP best“ und „Policy active“ zu einem grünen Zustand zusammenzieht, behauptet mehr als seine Daten beweisen. Die Norm hält ausdrücklich fest, dass BGP den SR Policy Candidate Path nicht selbst im Datenpfad installiert. BGP-Tabellenpräsenz ist ein Zustellbeleg, kein Vollzugsbeleg.

Der Distinguisher unterscheidet, erklärt aber nichts

Das SR-Policy-NLRI enthält Distinguisher, Color und Endpoint. Color und Endpoint bilden den Policy-Schlüssel. Mit verschiedenen Distinguishers kann ein Originator mehrere Candidate Paths derselben Policy oder Anzeigen für verschiedene Headends getrennt halten, ohne dass BGP sie als dieselbe Route behandelt.

Die Einschränkung folgt unmittelbar: Der Distinguisher hat keinen semantischen Wert. Eine größere Zahl ist weder neuer noch besser. Ein stabiler Wert garantiert keine unveränderte Absicht. Das Feld benennt keinen Dienst, keine Genehmigung und keine Vertrauensstufe. Es leistet Identitätstrennung, nicht Bedeutungszuweisung.

Für eine saubere Rekonstruktion braucht es deshalb mehrere Identitätsebenen. Das NLRI unterscheidet eine Anzeige. Color–Endpoint gruppiert Kandidaten unter einer Policy. Protocol-Origin und Discriminator markieren einen Kandidaten innerhalb des SRPM. Originator-Daten verweisen auf die Protokollquelle. Erst ein Change Record dokumentiert, welche Person oder Organisation die beabsichtigte Änderung freigegeben hat.

Der empfangende Knoten kann den BGP-Originator nach einer festgelegten Reihenfolge aus Route Origin Community, ORIGINATOR_ID oder Router ID des Peers ableiten. Das hilft hinter Route Reflectors, ist aber weder Firmenidentität noch Berechtigungsnachweis. Der direkte Nachbar kann der Übermittler, der Originator der technische Ursprung und der Freigebende eine dritte Instanz sein.

Auch symbolische Namen tragen diese Last nicht. Policy Name und Candidate Path Name sind optional und können bei der Signalisierung gekürzt werden. Sie helfen Menschen, eignen sich jedoch nicht als alleiniger Join-Key. Gleichnamigkeit kann zwei Policies verschmelzen; eine Umbenennung kann eine Policy künstlich verdoppeln.

BGP prüft den Umschlag, SRPM den Inhalt

Die Trennung bedeutet nicht, dass BGP blind ist. RFC 9830 definiert SAFI 73, zulässige AFIs, NLRI-Längen und die Form des Tunnel Encapsulation Attribute. Der Tunnel Type für SR Policy ist 15. Ein falscher Typ, ein unzulässig dupliziertes SR-Policy-TLV oder eine beschädigte Pflichtstruktur kann die Anzeige unbrauchbar machen und die Fehlerbehandlung treat-as-withdraw auslösen.

Damit kann eine fehlerhafte Route entfernt werden, ohne die ganze Sitzung zu verlieren. Die Sitzung bleibt verfügbar; die Semantik der überlebenden Kandidaten ist damit noch nicht bestätigt. BGP soll die einzelnen SR-Policy-Felder nicht semantisch verifizieren und ein UPDATE nicht allein aufgrund eines solchen Urteils verwerfen. Diese Prüfung gehört dem SRPM.

Störungsmeldungen müssen den Ort der Entscheidung erhalten. „Durch BGP-Strukturprüfung zurückgezogen“, „Sub-TLV ignoriert“, „nicht für dieses Headend importiert“, „vom SRPM semantisch abgelehnt“, „geeignet, aber nicht ausgewählt“ und „ausgewählt, aber nicht in der FIB“ haben andere Eigentümer und andere Reparaturwege. Ein pauschales „Policy ungültig“ löscht diese Information.

Erweiterungsregeln verschieben zudem, was an jeder Grenze sichtbar ist. Reservierte Bits werden null gesendet und beim Empfang ignoriert. Unbekannte oder unpassende Felder können entfernt werden. Bei manchen einmalig erlaubten Sub-TLVs zählt nur das erste Vorkommen. Die vom Controller erzeugten Bytes, die vom Reflector weitergegebenen Bytes und der an SRPM übergebene Informationssatz können voneinander abweichen. Für forensische Zwecke braucht jede Übergabe ihren eigenen Fingerabdruck.

Preference ist nicht die BGP-Präferenz

Mehrere ähnlich klingende Felder regeln verschiedene Ebenen. Candidate Path Preference beeinflusst die aktive Auswahl im SRPM, nicht den BGP-Best-Path. Priority ordnet die Neuberechnung von Policies nach einer Topologieänderung, nicht den Rang einer Route. Weight verteilt Verkehr auf gültige Segmentlisten innerhalb des gewählten Kandidaten; es beweist weder FIB-Installation noch die tatsächlich gemessene Verteilung.

Wer alle drei als „Priorität“ ablegt, kann eine Änderung nicht erklären. Eine neue Preference kann den aktiven Kandidaten wechseln, während die BGP-Tabelle unverändert bleibt. Eine neue Priority kann nur die Reaktionsreihenfolge ändern. Ein neues Weight kann den Anteil verschieben, ohne die Policy zu wechseln. Jedes Feld braucht Subjekt, Entscheidung und Wirkung.

Die Binding SID lässt ebenfalls lokale Autorität bestehen. Je nach Flags und Datenpfad kann das Headend eine signalisierte SID prüfen, übernehmen, selbst zuweisen oder ablehnen. Bestimmtes SRv6-Verhalten kann absichtlich opaque bleiben. Traffic Class, TTL oder Explicit-NULL-Verhalten dürfen unter definierten Bedingungen lokal überschrieben werden.

Die Anzeige ist somit keine fertige Anweisung. Ihre Bestandteile haben unterschiedliche Verbindlichkeit. Ein gutes System protokolliert „empfangen“, „akzeptiert“, „lokal überschrieben“, „ausgewählt“ und „installiert“ getrennt.

Beabsichtigtes Headend heißt nicht aktives Headend

In kleinen Netzen kann der Controller direkt zum Headend sprechen. Größere Domänen verwenden Route Reflectors oder mehrere AS innerhalb einer vertrauenswürdigen SR-Domäne. Route Targets markieren dabei die beabsichtigten Headends.

Der Route-Target-Import ist eine Publikumsentscheidung. Er besagt, dass die lokale Politik die Anzeige für diese Empfängerrolle vorgesehen sieht. Er belegt keine semantische Eignung, keinen Sieg über einen PCEP-Kandidaten, keine nutzbare Binding SID und keine Hardwareprogrammierung. Ein fehlendes Target kann einen korrekten Kandidaten aussperren; ein zu breites Target kann vertrauliche Pfadinformation an unnötige Router verteilen.

Die Vertraulichkeitsfrage reicht über Erreichbarkeit hinaus. Anzeigen können Endpoints, Knotennamen, SIDs und wirtschaftlich sensibles Pfaddesign offenlegen. Eine konfigurierte BGP-Sitzung autorisiert nicht automatisch jede Address Family und jeden Empfänger. Vertrauensdomäne, Peer-Rolle, SAFI, Route Targets und Exportpolitik brauchen einen eigenen Offenlegungsnachweis.

Route Reflection darf die Rollen nicht verwischen. „Von diesem Nachbarn empfangen“, „von diesem Controller originär erzeugt“ und „für diesen Geschäftszweck genehmigt“ sind drei Aussagen.

Ein Withdraw sagt nicht, was aufgehört hat

Wird eine BGP-SR-Policy-Route zurückgezogen, verschwindet eine Quellenkomponente. Das SRPM kann weiterhin einen BGP-Kandidaten mit anderem Distinguisher, einen PCEP-Kandidaten, eine lokale Konfiguration oder ein Backup besitzen. Die aktive Policy kann unverändert bleiben, umschalten, ungültig werden oder verschwinden. Der Withdraw bestimmt das Ergebnis nicht.

Umgekehrt kann ein neuer BGP-Best-Path dem SRPM übergeben werden, ohne den aktiven Datenpfad zu verändern. Seine Preference verliert vielleicht; ein Segment ist nicht verifizierbar; die Binding SID kollidiert; oder lokale Policy lehnt ihn ab. Die Zahl der BGP-Updates ist nicht die Zahl der Weiterleitungsänderungen.

Wirkungsnachweis verlangt eine längere Kette: rohes UPDATE und Hash; BGP-Strukturergebnis; beste Route des NLRI; Route-Target-Import; rekonstruierter Ursprung; SRPM-Semantik; vollständiger Kandidaten-Snapshot; aktive Auswahl; Binding-SID-Zustand; installierte Listen und Gewichte; RIB/FIB-Readback; beobachtete Pakete. Zeit, Gerät, Softwareversion und Reason Code gehören an jedes Glied.

Ein Mindeststandard schützt lokale Entscheidungsgewalt

RFC 9830 standardisiert die gemeinsame Sprache: Address Family, NLRI, Attribute, Kandidatenfelder, Weitergabe und Fehlerbehandlung. Damit können unabhängige Implementierungen eine Kandidatur austauschen. Die gemeinsame Schicht muss nicht jede lokale Konsequenz entscheiden.

Hier wird Heng Lus Prinzip der minimalen Anfangsspezifikation praktisch. Der Standard beseitigt die Transportmehrdeutigkeit; die lokale SRPM-Politik behält die folgenreichen Entscheidungen. Der Vorrang des laufenden Codes verlangt Belege vom tatsächlichen Headend und Datenpfad statt Vertrauen in das Prädikat „Standards Track“. Die Trennung der Realitätsebenen hält Vorschlag, ausgewählten Kontrollzustand und Paketwirkung auseinander.

Ein aussagekräftiger Test sendet zwei BGP-Kandidaten für ein Color–Endpoint-Paar mit verschiedenen Distinguishers und ergänzt einen höher bevorzugten PCEP- oder lokalen Kandidaten. Beobachtet werden BGP-Bestand, SRPM-Eignung, aktive Auswahl, Binding SID, FIB und Paketpfad. Danach wird jede Quelle einzeln entfernt. Kann die Überwachung die Übergänge nur als „BGP-Policy“ beschreiben, hat sie die von RFC 9830 erhaltene Autoritätsgrenze verloren.

Quellen