Zusammenfassung

  • RFC 9862 bildet eine SR Policy als PCEP Association und jeden Kandidatenpfad als LSP ab. Der Pfad ist die Signalisierungseinheit, manche Entscheidungen lassen sich jedoch nur für den vollständigen Verband bewerten.
  • Das INVALIDATION TLV trägt das Konfigurations-Flag D auf einem Kandidatenpfad. Aktiviert es irgendein Pfad, gilt Drop-Upon-Invalid für die gesamte SR Policy; wirksam wird es erst, wenn alle Kandidatenpfade ungültig sind.
  • Ein policyweiter Drop-Beleg sollte Fähigkeiten, vollständige Mitgliedschaft, Konfigurations- und Betriebsflags, die All-invalid-Schwelle, den ausgewählten Träger und das Paketergebnis verbinden. Das ist Daniel Kades redaktioneller Vorschlag, kein RFC-Feld und keine IETF-Vorgabe.

Eine rote Markierung neben einem Pfad sieht nach einer lokalen Eigenschaft aus. Sie kam in einem LSP-Objekt an, trägt die Kennung eines Kandidatenpfads und lässt sich sauber in dessen Datenbankzeile speichern. Diese Ablage entspricht dem Protokoll. Die Folgerung, auch die Wirkung ende an dieser Zeile, entspricht ihm nicht.

Drop-Upon-Invalid wird im INVALIDATION TLV eines Kandidatenpfads konfiguriert, aber nicht nur für diesen Pfad aktiviert. Ein einziges gesetztes Konfigurations-D bedeutet, dass die gesamte SR Policy die Funktion besitzt. Zu diesem Zeitpunkt wird noch nichts verworfen. Erst wenn sämtliche Kandidatenpfade ungültig geworden sind, tritt die Policy in den Drop-Zustand ein. Sie wählt den D-fähigen Pfad mit der höchsten Preference, zieht den betreffenden Verkehr weiter zum Headend und verwirft ihn dort, statt einen gewöhnlichen Ausweichweg zuzulassen.

Das Objekt mit der Absicht, die Menge an der Schwelle, die Policy mit dem neuen Zustand und die betroffenen Pakete haben unterschiedliche Reichweiten. Ein einzelnes D kann korrekt gespeichert sein und trotzdem eine falsche Kausalgeschichte erzeugen.

Ein Pfad als Nachricht, eine Menge als Entscheidungsraum

Eine SR Policy kann mehrere Kandidatenpfade enthalten. RFC 9862 führt die SR Policy Association, kurz SRPA, als PCEP-Darstellung der Policy ein; die LSPs der Association stehen jeweils für Kandidatenpfade. Das passt zur PCEP-Grammatik, denn der LSP ist die Einheit, die ein Sprecher ankündigt, aktualisiert und meldet.

Für Nachweise genügt diese Einheit nicht immer. Policyinformationen werden auf Kandidatenpfadebene transportiert, auch wenn ihre Bedeutung von allen Mitgliedern abhängt. Die SRPA liefert einen Join-Schlüssel. Ein Monitoring, das nur das alarmierende LSP behält, verliert dennoch die damalige Menge. Sitzungsneustarts, neue oder entfernte Pfade und Stichproben können den entscheidenden Kontext aus dem Verlauf schneiden.

Color und Endpoint identifizieren die Policy, Originator und Discriminator den Kandidatenpfad. Ein Pfad darf höchstens einer SRPA angehören, seine Kennung bleibt während der PCEP-Sitzung stabil und doppelte Kennungen innerhalb einer Policy sind ungültig. Damit ist Korrelation möglich. Eine zeitgebundene Momentaufnahme entsteht daraus nicht automatisch.

Auch die Fähigkeitsaushandlung beantwortet nur eine enge Frage. Beide Peers müssen SRPA-Unterstützung bekanntgeben, bevor sie die Association verwenden. Ein Sprecher, der sie bekanntgibt, muss jedes von ihm stammende SR-Policy-LSP einer SRPA zuordnen. Das SRPOLICY-CAPABILITY TLV trennt Fähigkeiten für Berechnungspriorität, Explicit NULL, Invalidation und stateless operation. Eine SRPA ohne ausgehandelte Fähigkeit führt zum Fehler und zum Sitzungsende. Das belegt ein gemeinsames Vokabular, nicht die Ungültigkeit aller Pfade oder einen Paketverlust.

Zwei D-Felder beschreiben zwei Tatsachenarten

Im INVALIDATION TLV gibt es Config und Oper. D in Config bedeutet, dass der Kandidatenpfad Drop-Upon-Invalid aktiviert. D in Oper bedeutet, dass das LSP aufgrund der aktivierten Funktion gerade Verkehr verwirft. Derselbe Buchstabe macht aus einer Absicht noch kein Ergebnis.

Die Nachrichtenrichtung gehört zur Semantik. PCE nach PCC übermittelt die Anweisung zum Aktivieren oder Deaktivieren. PCC nach PCE meldet die aktuelle Einstellung und den Drop-Zustand zurück. Wer nur den letzten D-Wert ohne Sprecher, Richtung, Sitzung und Zeitpunkt speichert, kann eine Anweisung als Bestätigung und einen Sollwert als Beobachtung lesen.

Normalerweise zieht ein ungültiges LSP keinen Verkehr mehr an. Der Verkehr kann über ein anderes LSP oder das IGP weiterlaufen. Drop-Upon-Invalid wählt absichtlich das Gegenteil: weiter anziehen und am Headend verwerfen. Für einen Dienst, bei dem eine unerlaubte Ausweichroute schlimmer als eine klare Unterbrechung wäre, kann das vernünftig sein. Bei veralteter oder falsch begrenzter Konfiguration kann es einen behebbaren Ausfall in eine gewollte Abschaltung verwandeln. Der Standard definiert den Mechanismus, nicht die Risikopräferenz des Betreibers.

Selbst ein Betriebs-D ist noch kein vollständiger Datenbeleg. Forwarding-Zähler müssen zeigen, ob Pakete ankamen, in welcher Menge sie verworfen wurden und wie lange. Steuerinformation, interpretierter Zustand und tatsächliche Wirkung bleiben getrennte Quellen.

Der letzte gültige Pfad löst den Policywechsel aus

RFC 9256 erklärt eine SR Policy für ungültig, wenn alle ihre Kandidatenpfade ungültig sind. Das ist ein Mengenprädikat. Der erste Ausfall mindert Redundanz, ein weiterer kann die aktive Wahl ändern, doch erst der Verlust des letzten gültigen Pfads überschreitet die Policyschwelle.

Dann prüft die Policy, ob irgendein Kandidatenpfad Drop-Upon-Invalid aktiviert hat. Falls ja, geht sie in den Drop-Zustand und aktiviert unter den D-Pfaden den mit der höchsten Preference. RFC 9862 verlangt nur, einen Kandidatenpfad mit dem Betriebs-D an den PCE zu melden. Das ist signalisierungseffizient, aber keine vollständige Ursache.

Angenommen, eine Policy hat drei Kandidaten. Ein alter Pfad mit niedriger Preference trägt aus einer früheren Entscheidung noch D; die beiden bevorzugten Pfade nicht. Fallen die beiden aus, beginnt noch kein Drop, solange ein Pfad gültig bleibt. Fällt der letzte, befähigt das alte Flag die gesamte Policy. Das LSP mit Betriebs-D zeigt den aktuellen Träger. Es verrät nicht, wer das Flag genehmigte, weshalb es noch bestand oder welche Zustandsänderung das Mengenprädikat vervollständigte.

Preference und computation priority dürfen ebenfalls nicht zusammenfallen. Die Preference wählt den besten Kandidaten: höhere Werte gewinnen, der RFC-9256-Standardwert ist 100. Die Berechnungspriorität aus RFC 9862 ordnet Neuberechnungen nach einer Topologieänderung: kleinere Werte kommen zuerst, ihr bedingter Standardwert ist 128. Ein generisches Feld „Priorität“ kann die Erklärung unbemerkt umdrehen.

Fehlende Werte können lokale Macht bedeuten

RFC 9862 kennt bedeutungsvolle Abwesenheit. Ist die Fähigkeit vorhanden, aber das TLV für Berechnungspriorität fehlt, gilt 128. Fehlt die Explicit-NULL-Policy, entscheidet lokale Konfiguration. Dieses TLV gilt für SR-MPLS, wird für SRv6 ignoriert, unbekannte Werte werden ebenfalls ignoriert, und der Betreiber darf signalisiertes Verhalten lokal überschreiben.

Ein leeres Feld kann also Default, Delegation, Nichtanwendbarkeit oder Überschreibung bedeuten. „Keine Policy“ ist nur eine mögliche, oft falsche Lesart. Für einen Drop-Vorfall braucht man den wirksamen Wert, seine Quelle, Vorrangfolge, Softwareversion und PCEP-Sitzung.

RFC 9862 verlangt, dass Betreiber die in der SRPA angekündigten Policy- und Kandidatenpfadkennungen sehen können. Außerdem sollen sie Peer-Fähigkeiten und die einer Policy zugeordneten LSPs anzeigen können. Diese Sichtbarkeit ist notwendig. Dauerhafte Erklärung entsteht erst, wenn die Ansichten zu einem Übergang verbunden werden.

Ein Beleg für die Ausweitung des Wirkungsbereichs

Der vorgeschlagene policyweite Drop-Beleg beginnt mit Color, Endpoint, SRPA, PCEP-Sitzung und den auf beiden Seiten gesehenen Fähigkeiten. Danach friert er die vollständige Kandidatenmenge der Entscheidung ein: Originator, Discriminator, Preference, Konfigurations-D und Gültigkeit jedes Pfads.

Anschließend folgt die Chronologie. Wann und nach welcher Quelle wurde jeder Pfad ungültig? Welcher war der letzte gültige? Wann wurde „alle ungültig“ wahr? Welche Kandidaten trugen D? Welcher wurde aufgrund seiner Preference als Drop-Träger gewählt? In welcher Richtung erschien das Betriebs-D? Unterschiede zwischen PCE-Absicht und PCC-Bericht bleiben sichtbar.

Zum Schluss wird das Datenresultat gebunden. Wurde Verkehr weiter in die Policy gelenkt? Welche Headend-Zähler zeigen Drops? Wann trat der erste und letzte auf? Kam die Erholung durch einen wieder gültigen Pfad, geänderte Konfiguration, andere Mitgliedschaft oder Rückzug der Policy? Eigentümer, geschützter Dienst, Ausnahme, Prüftermin und Rollback gehören dazu.

Das ist keine Forderung nach zentraler Topologiesammlung. SRPA und TLVs können zusätzliche Policyinformationen offenlegen. RFC 9862 übernimmt deshalb die Empfehlung für authentisierte und verschlüsselte PCEP-Sitzungen mit TLS zwischen PCE und PCC derselben administrativen Autorität. Der Beleg bleibt lokal, zugriffsgeschützt und minimal.

Er ist auch keine RFC-Erweiterung. Er ist eine redaktionelle Disziplin, damit der Codierungsort eines Bits nicht für den Wirkungsort der Entscheidung gehalten wird.

Sources