Zusammenfassung

  • RFC 9857 transportiert den Betriebszustand eines SR-Policy-Kandidatenpfads per BGP-LS, direkt vom Headend oder über einen PCE, der PCC-Zustand weitergibt.
  • Der Empfang belegt weder den Beobachtungszeitpunkt noch die aktuelle Generation oder unabhängige Bestätigungen aus FIB, Verkehr und Dienstbetrieb.

Der Rückkanal schließt nur die erste Lücke

Controller kennen ihre Absicht meist genauer als deren Ausführung. Sie können eine SR Policy berechnen oder verteilen, während der spätere lokale Zustand auf dem Headend in anderen Systemen verbleibt. RFC 9857 verkleinert diese Asymmetrie: Neue BGP-LS-NLRI und Attribute beschreiben Policy, Kandidatenpfade und Segmentlisten in einer interoperablen Form.

Damit erhält ein externer Verbraucher eine wertvolle betriebliche Aussage. Eine frisch eingetroffene Route kann allerdings eine ältere Beobachtung tragen. Nach einem Sitzungsneustart kann gespeicherter Zustand erneut angekündigt werden. Ein PCE kann eine Information weitergeben, die zuvor über PCEP vom PCC kam. Die lokale Empfangszeit datiert den Transport zum Verbraucher, nicht zwingend die Beobachtung an der Quelle.

Ein System darf deshalb „empfangen“ und „aktuell“ nicht als denselben Zustand behandeln. Der neue Rückkanal liefert die erste belastbare Antwort. Für zeitkritische Automatisierung braucht sie einen Herkunfts- und Altersnachweis.

Beschriebenes Headend und Berichtserzeuger sind zwei Rollen

Die Local Node Descriptors müssen nach RFC 9857 stets das Headend der SR Policy bezeichnen. Kündigt ein PCE einen vom PCC über PCEP gelernten Zustand an, darf er dort nicht seine eigenen Kennungen einsetzen. Eigene BGP-Router-ID-, AS- oder Konföderationsangaben kann der PCE im BGP-LS-Attribut führen.

Diese Trennung hält das beschriebene Objekt stabil. Sie verlangt zugleich, dass der Empfänger zwei Provenienzen speichert: Wem gehört die Policy, und wer erzeugte die konkrete BGP-LS-Meldung? Wer nur das Headend festhält, macht aus einer zulässigen Weitergabe scheinbar eine Direktbeobachtung. Wer nur den BGP-Nachbarn festhält, verliert den Gegenstand des Berichts.

Protocol-Origin benennt wiederum den Ursprung der Instanziierung, etwa PCEP, BGP SR Policy oder lokale Konfiguration. Das Feld ist keine Beobachteridentität, keine Messzeit und keine Hardwarequittung. Auch die BGP-LS Instance-ID ist kein Zeit- oder Versionszähler, sondern unterscheidet Routing-Instanzen.

Ein aktiver Kandidat ist eine starke, begrenzte Aussage

Das Bit A kennzeichnet einen aktiven Kandidatenpfad und bedeutet im Sinn von RFC 9256, dass er in der Weiterleitungsebene bereitgestellt ist. Diese Produzentenaussage hat operatives Gewicht. Sie ist aber nicht dasselbe wie eine unabhängig korrelierte Bestätigung jedes ASIC oder jeder Linecard.

Die weiteren Bits haben eigene Bedeutungen: S steht für administrative Abschaltung, B für Backup, E für Auswertung, V für mindestens eine gültige Segmentliste, D für Delegation und C für PCE-Bereitstellung. I, T und U beschreiben definierte Drop- oder Transitfähigkeiten. Segmentlisten melden Berechnung, Verifikation, Auflösung und Topologiebezug; M zeigt eine Entfernung nach einem durch Monitoring festgestellten Fehler.

Damit lässt sich die lokale Entscheidung genauer lesen. Keines dieser Bits zählt jedoch Pakete, bestätigt die Nutzung genau dieser Generation oder misst den Erfolg des Dienstes.

Der Empfänger muss eine zeitliche Klammer ergänzen

RFC 9857 definiert keinen verpflichtenden Beobachtungszeitstempel am Produzenten, keine monotone Generationsnummer, keine getrennte SRPM-Quittung und keinen FIB-Nachweis. RFC 9552 erlaubt zudem eine durch Richtlinien gesteuerte zeitliche Bündelung von BGP-LS-Aktualisierungen. Ausbleibende Nachrichten können Stabilität, Drosselung oder verlorene Kontinuität bedeuten.

Ein Controller braucht daher eine eigene Epoch-Grenze: Identität von Headend und Produzent, Sitzung und Neustarts, Empfangszeit, Absichtsgeneration sowie ein zulässiges Höchstalter. Wechselt der PCE, die Delegation oder die Sitzung, sollte eine vorherige Aktualitätsannahme verfallen, bis passende neue Evidenz vorliegt.

Das ergänzt keine erfundene Protokollsemantik. Es verhindert, dass die Anwendung aus einem Zustandsfeld eine zeitliche Garantie ableitet, die dort nicht kodiert ist.

Vom Bericht zum Dienst sind fünf Quittungen nötig

Die BGP-LS-Meldung beantwortet, welchen Zustand der Produzent veröffentlicht. Eine SRPM-Quittung beantwortet, welche Generation der lokale Policy Manager angenommen hat. Ein FIB- oder Hardwarebeleg zeigt, was tatsächlich programmiert wurde. Verkehrstelemetrie zeigt, welchen Weg Pakete nutzen. Dienstmetriken zeigen schließlich, ob Latenz, Verlust und Verfügbarkeit das Ziel erfüllen.

Diese Belege entstehen in verschiedenen Takten und können in anderer Reihenfolge eintreffen. Ihre Verknüpfung braucht einen stabilen Policy- und Kandidatenpfadschlüssel, vergleichbare Generationen und ein ausdrückliches Zeitfenster. Fehlt eine Quittung, muss diese Lücke sichtbar bleiben. Der letzte grüne Wert darf sie nicht ausfüllen.

So entsteht eine ehrliche Abstufung: empfangen, lokal bestätigt, in der Weiterleitung bestätigt, im Verkehr beobachtet und im Dienst verifiziert. RFC 9857 stärkt die erste Stufe und kann die Suche nach den weiteren auslösen. Es ersetzt sie nicht.

Register und Erratum sichern die Wortbedeutung

Das IANA-Register führt die für das Verfahren vorgesehenen BGP-LS-Typen und TLVs. Beim RFC Editor ist das verifizierte Erratum 8709 verzeichnet; es ändert an drei Stellen „SR Binding SID sub-TLV“ in „SR Binding SID TLV“. Das ist eine relevante redaktionelle Präzisierung, aber kein neuer Zeit- oder Installationsnachweis. Register und Errata bestätigen die normative Lesart, nicht das Verhalten eines bestimmten Produkts.

Quellen