Zusammenfassung

  • Der PCE-Arbeitsgruppenentwurf, Revision 03, will S-BFD zunächst im OPEN-Austausch aushandeln und anschließend pro LSP über PCEP steuern. Der PCE sendet, der PCC berichtet.
  • Bei B=1 ist ein Remote Discriminator Pflicht. Bei B=0 widersprechen sich zwei Abschnitte zum Umgang mit Parametern; das Weglassen des ganzen Felds steht als weitere Idee in einer redaktionellen Notiz.

Ein Planer kann sprechen, ein Router muss handeln

Ein Path Computation Element (PCE) plant Pfade. Ein Path Computation Client (PCC) betreibt den Pfad auf dem Gerät, das eine Fehlererkennung tatsächlich ausführen kann. Der aktuelle Entwurf zu BFD-Parametern in PCEP will diese Rollen für Seamless Bidirectional Forwarding Detection (S-BFD) verbinden. Der PCE soll eine Konfiguration für einen Label-Switched Path (LSP) anstoßen können. Das klingt nach einem Schalter in der Leitstelle. Der Schalter sitzt jedoch auf einem anderen Rechner als der Detektor.

Vor jedem LSP-Kommando steht die Fähigkeitsverhandlung. Im OPEN-Objekt kann ein Sprecher ein LSP-S-BFD-Capability TLV senden. Empfängt die Gegenseite darin B=1, kann sie die neuen S-BFD-TLVs mit diesem Peer austauschen. Fehlt das Feld oder steht B im OPEN auf null, darf sie keine S-BFD-TLVs im LSPA-Objekt an ihn senden. Auch die Liste der unterstützten Path Setup Types muss zur allgemeinen Liste der PCEP-Sitzung passen. Ein nicht unterstützter Typ führt laut Entwurf zu PCErr Typ 21, Wert 2, und zur Schließung der Sitzung. Ohne gemeinsamen S-BFD-Pfadtyp lässt sich ein neu angelegter LSP über diesen PCEP-Mechanismus nicht mit S-BFD versehen.

Das ist eine Grenze für das gemeinsame Protokoll. Der PCC kann S-BFD nach eigener lokaler Regel dennoch verwenden. Umgekehrt schaltet eine erfolgreiche OPEN-Verhandlung keinen einzigen LSP scharf. Sie sagt nur, dass beide Seiten die vorgeschlagene Sprache verstehen. Ein Netzinventar, das „S-BFD-fähig“ und „S-BFD läuft“ in einer Spalte führt, spart Platz auf dem Bildschirm und verliert den wichtigsten Unterschied bei einer Störung.

Das LSP-Kommando verwendet ein anderes Feld. Der LSP-S-BFD TLV liegt im LSPA-Objekt. Der PCC meldet ihn in PCRpt; der PCE schickt ihn in PCInit oder PCUpd. Das B im OPEN-Feld betrifft die Fähigkeit zwischen Peers. Das B im LSP-Feld betrifft einen bestimmten Pfad. Gleicher Buchstabe, verschiedene Zuständigkeit. Wer die beiden gleichsetzt, verwechselt die Erlaubnis zum Reden mit der Antwort auf ein konkretes Kommando.

Einschalten ist präzise, Ausschalten noch nicht

Steht B im LSP-Feld auf eins, soll S-BFD auf diesem Pfad angewendet werden. Dafür verlangt der Entwurf einen Sub-TLV mit dem Remote Discriminator; fehlt er, ist ein Fehler vorgesehen. Ein weiterer, optionaler Sub-TLV überträgt das minimale Sendeintervall und einen Multiplikator zwischen 1 und 255. Das sind überprüfbare Werte. Ein Logeintrag „B=1 gesendet“ ohne den erforderlichen Discriminator belegt eine Absicht, aber keine vollständige Anfrage nach dem Entwurf.

Bei B=0 nennt Abschnitt 4.3.2.1 zunächst einen klaren Ausgang: Eine Aktualisierung durch den PCE entfernt S-BFD, eine PCE-initiierte Neuanlage wendet es nicht an. Abschnitt 4.2 ergänzt Sonderfälle. Hatte der PCC für den LSP gar kein S-BFD angewendet, muss er eine B=0-Aktualisierung ignorieren. Für einen vom PCC initiierten LSP darf der PCE unter derselben Voraussetzung das B=0 ignorieren. An einem leeren Haken lässt sich nichts abhängen. Der Unterschied muss aber im Betriebsprotokoll stehen: „Abschalten angefordert“ ist nicht automatisch „laufenden Detektor entfernt“.

Die eigentliche Kollision betrifft Parameter, die mit B=0 eintreffen. Abschnitt 4.2 sagt, ein PCEP-Sprecher darf den Parameter-Sub-TLV ignorieren; Ignorieren oder Speichern sei eine Implementierungsentscheidung. Abschnitt 4.3.2.2 sagt, er muss ihn ignorieren. Eine redaktionelle Notiz bietet noch eine zweite Abschaltlogik an: Wenn der gesamte LSP-S-BFD TLV nicht mehr eintrifft, soll bereits vorhandenes S-BFD entfernt werden. Diese Notiz ist ein Alternativvorschlag. Ein ausdrücklich gesendetes B=0 und ein gar nicht gesendetes Feld sind auf der Leitung verschieden. Software kann nicht beides stillschweigend zu einer einzigen „Aus“-Taste erklären, solange der gemeinsame Text die Frage offenlässt.

Ein PCC kann auch aus anderen Gründen Nein sagen. Wer ein S-BFD-LSP-Feld ohne ausgehandelte Fähigkeit erhält, muss dessen Inhalt ignorieren und einen PCErr vom Typ 19 zurückgeben. Ein Multiplikator außerhalb von 1 bis 255 führt zu Typ 23. Der Entwurf fordert neue Werte und TLV-Typen bei IANA an, führt sie aber noch als TBD. Ein Fehlerbericht kann die Kategorie benennen. Die nicht vergebenen Zahlen gehören nicht in eine Tabelle „bereits registrierte Codes“.

Eine weitere Grenze sitzt in den Assoziationsgruppen. Abschnitt 6 sagt, dass manche Implementierungen für LSPs derselben Gruppe gleiche S-BFD-Parameter verlangen. Weichen minimales Sendeintervall, Multiplikator oder Remote Discriminator ab, sollte der Sprecher einen Assoziationsfehler vom Typ 26 zurückgeben. „Manche“ ist hier kein lästiges Kleingedrucktes. Es trennt eine mögliche Gerätebeschränkung von einer allgemeinen Regel. Der PCE kann eine aus seiner Sicht stimmige Kombination vorschlagen, die der PCC vor Ort ablehnt. Der Bericht muss erkennbar machen, ob die Ablehnung aus der Fähigkeitsverhandlung oder aus dieser lokalen Beschränkung kam.

RFC 7880 beschreibt S-BFD selbst. RFC 8231 und RFC 8281 liefern den Rahmen für Stateful PCEP und vom PCE angestoßene LSPs; der Entwurf verweist auch auf RFC 9050 zum PCE als zentralem Controller. Diese RFCs erklären, warum der Vorschlag in eine bestehende Architektur passt. Die neue S-BFD-Erweiterung ist weiterhin ein Internet-Draft. Revision 02 und Revision 03 unterscheiden sich im Wesentlichen bei Datum, Ablauf und Seitenangaben. Die zwei Verben für B=0 blieben stehen. Ein frischer Versionsstempel hat den Widerspruch nicht gelöst.

Ein belastbarer Test muss für denselben LSP sechs Spuren verbinden: OPEN-Fähigkeit, gemeinsamen Pfadtyp, PCInit oder PCUpd, den PCRpt des PCC, die wirksame Konfiguration und den Zustand der S-BFD-Sitzung. Die ersten beiden erlauben das Gespräch. Die Nachricht zeigt den Auftrag. Der Bericht zeigt die Antwort des PCC. Die letzten beiden zeigen, was das Gerät tatsächlich ausführt. Ob der Pfad gesund ist, beantworten wiederum eigene Messungen. Die Zahl der gesendeten Befehle ist dafür kein Ersatz.

In den hier herangezogenen offiziellen Dokumenten fehlt ein Testprotokoll, das B=0 oder B=1 dieser Erweiterung mit Bericht, Konfiguration und laufender Sitzung eines benannten PCC verbindet. Eine solche zusammenhängende Spur würde das Verhalten dieser Implementierung klären. Für den gemeinsamen Standard bleibt die Entscheidung auf dem Tisch: Darf man Parameter bei B=0 ignorieren oder muss man es? Und gilt Schweigen auf der Leitung als Auftrag zum Löschen?

Quellen