Zusammenfassung

  • Der Entwurf vom 28. Oktober schlägt zwei PCEP-FlowSpec-TLVs für Felder gewöhnlicher SRv6-SIDs und komprimierter SID-Container vor. Beide Sitzungspartner müssen zuvor ein neues S-Bit signalisieren.
  • Ein PCC muss bei fehlender Aushandlung oder fehlerhafter Struktur PCErr Typ 30 senden. Als Wert nennt der Text TBD_EV, fordert dafür aber keine IANA-Zuteilung an. Im bestehenden Register sind „nicht unterstützt“ und „fehlerhaft“ bereits getrennt nummeriert.

Im Befehl steckt jedes Bit. Im Widerspruch fehlt eines.

Der individuelle Internet-Draft macht die PCEP-Steuerung feiner. Ein PCE kann einen FlowSpec-Abgleich auf Locator, Function und Argument einer normalen SRv6-SID beziehen. Ein zweites TLV soll Locator-Block, Locator-Node und Function eines komprimierten SID-Containers erfassen. Damit legt die zentrale Instanz nicht bloß eine Zieladresse fest, sondern auch, wie deren innere Struktur für den Filter zählt. Der PCC auf dem Router setzt die Regel um.

Vor dem Versand müssen beide Seiten das S-Bit in ihrer Fähigkeitserklärung setzen. Fehlt die beiderseitige Aushandlung, gehört das neue TLV nicht in die PCEP-Nachricht. Beim Empfang kontrolliert der PCC außerdem, ob die angegebenen Feldlängen zusammen höchstens 128 Bit ergeben. Diese Prüfung ist eine konkrete Schranke gegen Anweisungen, deren Feldplan länger als die Adresse ist.

Eine Schranke braucht eine lesbare Antwort. Abschnitt 5.2 verlangt für nicht ausgehandelte oder fehlerhafte SRv6-Komponenten eine PCErr-Nachricht mit Error-Type 30 und Error-Value TBD_EV. Abschnitt 7 beantragt bei IANA jedoch nur das S-Bit und zwei TLV-Typen. Die Fehlernummer taucht dort nicht auf. Das IANA-Register für PCEP kennt für Typ 30 die Werte 1 bis 5; die Werte 6 bis 255 sind frei. Das Kürzel im Entwurf ist keine Zahl, die zwei Implementierungen verlässlich auf der Leitung austauschen können.

Der Vorgängertext bietet sogar schon eine Unterscheidung an. RFC 9168 verwendet Wert 1 für „Unsupported FlowSpec“ und Wert 2 für „Malformed FlowSpec“. Der neue Entwurf bündelt beide Fälle in einem provisorisch benannten SRv6-Fehler. Die Autoren können die vorhandenen Werte ausdrücklich übernehmen. Sie können auch einen neuen, gemeinsamen Wert definieren und beantragen. Im vorliegenden Text bleibt die Entscheidung offen, obwohl die Antwort verpflichtend sein soll.

Das Problem zeigt sich am ehesten, wenn eine Regel scheitert. Ein PCE kann wissen, welches Teilfeld es prüfen lassen wollte. Ohne gemeinsame Fehlerkodierung erfährt es womöglich nicht eindeutig, ob der Router die Funktion gar nicht ausgehandelt hatte oder ob die übermittelte Struktur kaputt war. Zwei Anbieter könnten denselben gültigen Filter verstehen und bei dessen Ablehnung auseinanderlaufen. Der Fehlerkanal wäre dann die unpräziseste Stelle eines erstaunlich präzisen Befehls.

Laut IETF Datatracker handelt es sich um einen individuellen Entwurf. Eine folgende Version kann die offene Zahl mit einem Verweis auf RFC 9168 oder einem IANA-Antrag schließen. Wer die nächste Fassung prüft, sollte bei der Pflicht zum Ablehnen beginnen, nicht bei der glänzenden neuen Filterfunktion.

Quellen