Zusammenfassung

  • Für die Segmenttypen I, J und K darf RFC 9831 ein SRv6-SID-Feld mit dem Nullwert enthalten, wenn Verhalten oder Struktur beschrieben werden sollen, ohne die ausführbare SID vorzugeben.
  • Das S-Flag belegt die Anwesenheit des Feldes, nicht die Lieferung eines nutzbaren Werts. Das Headend löst Knoten oder Adjazenz mit lokalen SR-Informationen auf und kann fehlende oder widersprüchliche Ergebnisse zurückweisen.
  • Eine belastbare Beweiskette hält Flags, Rohwert, Referenzkontext, Informationsstand, aufgelöste SID, Prüfgrund, Auswahl, Installation und Paketbeobachtung getrennt.

Vollständig übertragen, bewusst unvollständig bestimmt

Ein optionales Feld scheint zunächst nur zwei Zustände zu kennen: vorhanden oder nicht vorhanden. Bei den SRv6-Typen I, J und K entsteht ein dritter. Das S-Flag kann ein 16-Octet-SID-Feld ankündigen, dessen Wert die IPv6-Nulladresse ist.

Der Controller darf diesen Wert verwenden, wenn er Endpoint Behavior oder SID Structure mitteilen, aber keine konkrete SID festlegen will. Die Nachricht ist auf dem Draht vollständig. Inhaltlich übergibt sie einen noch offenen Schritt an den Empfänger.

Fehlt das SID-Feld, darf auch der Behavior/Structure-Block nicht enthalten sein. Ist das Feld mit Null vorhanden, kann der Block zusätzliche Erwartungen transportieren. Enthält es eine Nichtnull-SID, hat der Sender einen konkreten Wert angegeben. Abwesenheit, Null mit Kontext und konkreter Wert sind drei unterschiedliche Übergaben.

Wer die ersten beiden als null speichert, löscht die Delegation. Wer die letzten beiden als „SID vorhanden“ zusammenfasst, erklärt eine offene Auflösung zur fertigen Anweisung. Erforderlich sind S, B, der unveränderte 128-Bit-Wert, der Segmenttyp und die Knoten- oder Linkbeschreibung.

Eine explizite Route kann lokale Auflösung verlangen

Die Segment List sub-TLV beschreibt einen expliziten Pfad zum Endpoint; jede Segment sub-TLV ist ein geordnetes Element. Explizit sind Absicht, Typ und Reihenfolge. Nicht jedes Element muss bereits als MPLS-Label oder SRv6-SID vorliegen.

Die Typen C und D beschreiben IPv4- beziehungsweise IPv6-Knoten für SR-MPLS. E bis H identifizieren Adjazenzen mit Adressen und Interface-IDs. I bis K übertragen entsprechende Referenzen für SRv6. RFC 9256 weist dem Headend die Auflösung dieser Beschreibungen in Label oder SID zu.

Dadurch muss ein Controller nicht jede aktuelle lokale Zuweisung des Empfängers in seiner Nachricht festschreiben. Änderungen innerhalb einer Domäne können hinter derselben Referenz verarbeitet werden. Die Kehrseite ist eine ausführungsrelevante Abhängigkeit vom Wissensstand des Headends.

Zwei Headends können aus identischen Bytes verschiedene Ergebnisse gewinnen. Eines besitzt die aktuelle Prefix- oder Adjazenzinformation; das andere findet keinen Eintrag oder einen abweichenden Wert. Das empfangene Attribut allein erklärt diesen Unterschied nicht. Quelle, Version und Zeitpunkt der lokalen SR-Sicht gehören zum Nachweis.

Vier Bits sind keine gemeinsame Ampel

Das A-Flag macht das Feld SR Algorithm für bestimmte Typen bedeutungsvoll. Ist A nicht gesetzt, muss der Sender dort Null schreiben und der Empfänger das Feld ignorieren. Dieser Nullwert delegiert keine Algorithmuswahl; er enthält schlicht keine entsprechende Aussage.

S belegt die Anwesenheit des SID-Felds. Es sagt nicht, ob der Wert Null ist, lokal existiert, zur Referenz passt oder installiert werden kann.

B kündigt bei B, I, J und K den SRv6-Block für Endpoint Behavior und SID Structure an. Er darf nicht ohne SID-Feld auftreten, kann aber ein SID-Feld mit Null begleiten. Damit beschreibt B Erwartungen an einen Wert, den das Headend noch ermitteln soll.

V fordert die SID-Prüfung durch SRPM an. Es ist kein Ergebnisbit. V=1 als „verifiziert“ anzuzeigen, macht aus einem Prüfauftrag eine erfundene Bestätigung.

A, S, B und V verteilen Bedeutung, Präsenz, Zusatzkontext und Prüfung auf getrennte Schritte. Ein einziger Status „gültig“ kann diese Zuständigkeiten nicht darstellen.

Das Headend darf einen gelieferten Wert widerlegen

RFC 9256 beschreibt die SR-DB als konzeptionellen Informationsbestand für Berechnung und Prüfung. Eine Implementierung muss keine tatsächliche Datenbank dieses Namens bauen. Sie benötigt aber lokale Belege, um Prefix, Knoten, Interface oder Adresspaar einer aktuellen SID zuzuordnen.

Eine Prüfung kann scheitern, weil eine gelieferte SID nicht gefunden wird. Sie kann scheitern, weil der Kontext eines Typs C–K zu einer anderen SID führt. Oder ein nicht erstes Segment lässt sich überhaupt nicht auflösen. Diese Ursachen bedeuten Wissenslücke, Widerspruch oder unvollständigen Pfad und brauchen unterschiedliche Besitzer.

Über Domänengrenzen wird die Reichweite lokaler Erkenntnis anerkannt. Kann das Headend die Erreichbarkeit entfernter SIDs nicht prüfen, verlangt RFC 9256 für sie die direkten Typen A oder B; die erste SID muss stets erreichbar sein. Die Darstellung wird dort direkter, wo Kontextprüfung nicht mehr zuverlässig möglich ist.

Das Headend decodiert also nicht nur. Es bestimmt anwendbare Felder, konsultiert den lokalen Stand, ergänzt einen Wert, vergleicht Behauptung und Auflösung und bewertet die Liste. Die Authentisierung eines BGP-Peers schützt die Herkunft, nicht die Richtigkeit seiner Knotenadresse, Interface-ID, Behavior-Angabe oder Topologiesicht.

Syntax kann stimmen, während der Pfad scheitert

RFC 9831 legt abhängig von SID und Behavior/Structure genaue Längen fest. Ihre Prüfung verhindert verschobene Feldgrenzen. Sie belegt, dass die erwarteten Bytes angekommen sind, nicht dass sie gemeinsam ausgeführt werden können.

Der Typ bestimmt die strukturelle Rolle, Flags die auszuwertenden Felder, SRPM die Semantik des Gesamtpfads. Eine Mischung aus SR-MPLS- und SRv6-Segmenten macht eine Liste nach RFC 9256 ungültig, selbst wenn jede einzelne sub-TLV perfekt geformt ist.

RFC 9830 trennt die semantische Prüfung expliziter Pfade bereits von BGP. RFC 9831 ändert laut eigener Aussage weder SR-Policy-Betrieb noch Fehlermanagement. Die vorherige Analyse zu RFC 9830 behandelte BGP-Transport gegenüber Weiterleitungsautorität. Hier liegt die Grenze im transportierten Inhalt: Ein vorhandenes Feld kann noch die Aufforderung zur lokalen Vervollständigung sein.

Der IANA-Eintrag erzeugt keinen laufenden Pfad

IANA koordiniert die Werte der Typen C–H und I–K sowie die Bits A und S. So lesen unterschiedliche Implementierungen dieselben Nummern als dieselbe Grammatik. Der Eintrag liefert aber weder Topologie noch aktuelle SID noch Hardwareunterstützung.

Type J im Register beweist keine Routerunterstützung. Eine Interface-ID beweist keinen unveränderten Link. Eine aufgelöste SID beweist keine Programmierung; diese beweist keinen beobachteten Paketlauf. Auch Experimental als Dokumentstatus ist keine Aussage zur Verbreitung.

„Unterstützt“ kann beim Parser enden. „Aufgelöst“ verlangt lokalen Kontext. „Verifiziert“ verlangt den Vergleich. „Aktiv“ betrifft die Kandidatenauswahl. „Installiert“ gehört zur Weiterleitung. „Beobachtet“ verlangt eine kontrollierte Messung. Die Begriffe müssen in Betriebsberichten getrennt bleiben.

Original und Ergebnis gemeinsam aufbewahren

Der Controller-Beleg hält Absicht, Reihenfolge, Typ, Knoten-/Linkkontext, A/S/B/V, Längen, Rohwerte, Version und Zeit fest. Er benennt Nichtnull-SID, Null zur Delegation oder Feldabwesenheit ausdrücklich.

Der Headend-Beleg ergänzt Quellen und Version der SR-Informationen, Ergebnis, Mehrdeutigkeit und Zeitpunkt. Der Prüfbeleg nennt Fund, Übereinstimmung, Technologiemischung und Ablehnungsgrund. Erst danach folgen Kandidatengültigkeit, aktive Auswahl, Programmierung, Paket und Servicewirkung.

So geht eine fehlgeschlagene Delegation an den Besitzer lokaler Information, ein Widerspruch zum Sender an die Übergabegrenze und ein später Installationsfehler an die Weiterleitungsplattform. Mehr Zustände bedeuten hier weniger Streit, weil sie den Ort der Entscheidung erhalten.

Quellen