Zusammenfassung

  • RFC 9756 reserviert experimentelle PCEP-Fehlertypen. Die beteiligten Parteien vereinbaren deren Bedeutung, erhalten damit aber keine dauerhafte oder weltweit exklusive Zuweisung.
  • Der Weg zur Standardisierung verlangt IANA-Zuweisungen für die Fehlerpaare. Ein Austausch von Zahlen im Programm ersetzt keine abgestimmte Migration des Betriebs.
  • Zur Abnahme gehören deshalb auch Diagnosewerkzeuge, historische Aufzeichnungen und die Bedeutung, die ein zurückgesetzter Softwarestand wieder einführt.

Bei einer technischen Abnahme lässt sich leicht nachweisen, dass eine neue Version funktioniert. Schwieriger ist der Nachweis, dass eine alte Vereinbarung nicht mehr gebraucht wird.

Dieser Unterschied wird relevant, wenn ein Netzversuch eigene Fehlernummern verwendet. Beide Seiten verstehen sie, die Tests gelingen, und der Betrieb übernimmt die Fehlermeldungen in seine Abläufe. Nach der regulären Zuweisung werden die Nummern im Programm ersetzt. Das wirkt wie eine kleine Änderung. Doch die alte Bedeutung kann in Alarmregeln, Supportanleitungen und einem Notfallabbild weiterleben.

Das ist ein hypothetisches Betriebsszenario, kein hier belegter Produktfehler. Es zeigt, welche Abnahmefrage hinter RFC 9756 liegt. Das im März 2025 veröffentlichte Dokument schafft einen klareren Platz für experimentelle PCEP-Fehler und erleichtert den Weg erfolgreicher Versuche in die Standardisierung. Es liefert keinen fertigen Migrationsplan für den Gerätebestand eines Betreibers.

Ein Paar von Zahlen und ein begrenzter Teilnehmerkreis

PCEP dient dem Austausch im Zusammenhang mit der Pfadberechnung. Nach der Grundspezifikation RFC 5440 enthält ein Fehlerobjekt einen Error-Type und einen Error-value. Der Typ bezeichnet die Fehlerklasse, der Wert ergänzt Einzelheiten. Die Bedeutung entsteht aus dem Paar, nicht aus einer losgelösten Zahl.

Im PCEP-Register von IANA sind die Typen 252–255 samt ihren Werten 0–255 für Experimente reserviert. Für die Typen 0–251 und ihre Werte gilt IETF Review. Die Versuchsteilnehmer stimmen ab, welche Paare sie verwenden und wofür diese stehen. Laufen mehrere Experimente gleichzeitig mit denselben Implementierungen, müssen ihre Paare auseinandergehalten werden.

Die reservierte Fläche ist keine exklusive Herstellernische. Ein anderes Experiment kann denselben Zahlen eine andere Bedeutung geben. Auch ein noch nicht zugewiesener Wert unter einem regulären Fehlertyp ist kein Ausweg: RFC 9756 sieht experimentelle Werte gerade nicht innerhalb gewöhnlicher Fehlertypen vor.

Damit wird die Teilnehmergrenze zu einer Betriebsbedingung. Neue Gegenstellen, gemeinsam genutzte Implementierungen und zusätzliche Versuche können den ursprünglichen Konsens verändern. Eine Abnahme, die nur die erste erfolgreiche Verbindung dokumentiert, erfasst diese späteren Kombinationen nicht.

Warum vorläufige Nummern langlebig werden

RFC 3692 beschreibt die Schwierigkeiten, temporär zugewiesene Nummern wieder einzuziehen. Ansprechpartner werden unerreichbar, das Ende eines Versuchs bleibt unklar, und Produkte können die Nummer weiter nutzen. Eine spätere Wiederverwendung könnte dann noch vorhandene Geräte treffen.

Experimentelle Bereiche vermeiden die Notwendigkeit, für jeden Versuch eine gewöhnliche Zuweisung zu belegen. Sie sind aber nicht für allgemeine Verbreitung oder standardmäßig aktivierte Erkennung in ausgelieferten Produkten gedacht. Nutzer müssen den experimentellen Einsatz ausdrücklich einschalten und die Werte konfigurieren; je nach Produkt kann dies durch ausdrückliche Neuprogrammierung erfolgen. Auch ein Konsortium kann durch Einigung keine weltweite Eindeutigkeit schaffen.

Der praktische Schluss lautet nicht, Experimente unnötig schwer zu machen. Er lautet, ihre Grenzen und ihr Ende verwaltbar zu halten. Die Nummer benötigt einen bekannten Kontext. Wird dieser Kontext stillschweigend größer, wächst eine Abhängigkeit, ohne dass jemand ihre dauerhafte Unterstützung beschlossen haben muss.

Dabei tragen mehrere Teams bei. Die Entwicklung hinterlegt einen Wert, die Überwachung ergänzt eine Regel, der Support lernt ein Suchmuster. Jede Maßnahme kann sinnvoll sein. Zusammen machen sie aus einer lokalen Implementierungsänderung eine bereichsübergreifende Migration.

Eine gemeinsame Fehlerstruktur statt eines Sonderwegs

Bereits RFC 8356 reservierte experimentelle Bereiche für PCEP-Nachrichten, Objekte und TLVs. Für weitere Funktionen konnte ein Experiment ein eigenes Objekt oder TLV verwenden.

RFC 9756 bewertet diesen Umweg bei Fehlern als unnötige Abweichung im Code. Ein Sonderobjekt für beliebige experimentelle Fehler würde mehr Distanz zum regulären Fehlermodell schaffen. Die Nutzung der vorhandenen Fehlerstruktur erleichtert deshalb den Übergang erfolgreicher Experimente auf den Standards Track.

Die verwendeten Zahlen bleiben dennoch vorläufig. Sobald die Arbeit in Richtung einer Standards-Track-Veröffentlichung geht, braucht jedes Paar eine IANA-Zuweisung. Möglich sind ein neuer Typ mit seinen Werten oder zusätzliche Werte unter einem bestehenden Typ. Der Erfolg des Versuchs entscheidet nicht von selbst über diese spätere Form.

Der RFC beschreibt die Anpassung in der Implementierung als Ersetzen numerischer Werte. Daraus folgt weder automatische Verständigung zwischen alten und neuen Wörterbüchern noch eine universelle Unterstützung gemischter Versionen. Wer solche Eigenschaften benötigt, muss sie an der konkreten Implementierung prüfen. Fehlt kontrollierte Koexistenz, kommen ein isolierter Versuch oder ein abgestimmter Wechsel mit begrenztem Umfang in Betracht.

Historische Daten brauchen historischen Sinn

RFC 9756 empfiehlt, die tatsächlich gewählten experimentellen Zahlenpaare nicht in öffentlichen Dokumenten festzuhalten. Textuelle oder symbolische Namen können die Fehler verständlich beschreiben. So wird eine vorläufige Wahl nicht durch wiederholte Dokumentation zum vermeintlichen dauerhaften Vertrag.

Das ist nicht mit dem Verzicht auf Diagnosebelege gleichzusetzen. Für einen Betriebsdatensatz können das ursprüngliche Zahlenpaar, Zeit, Gegenstelle sowie Versuchsversion oder Decoderstand wichtig sein. Diese Felder sind hier vorgeschlagene Prüfpunkte, kein vom RFC vorgeschriebenes Protokollierungsschema. Maßgeblich ist, was sich zuverlässig erfassen und angemessen schützen lässt.

Ein hypothetisches Beispiel verdeutlicht den Unterschied. Ein aktualisiertes Diagnosewerkzeug liest einen alten Vorfall und wendet sein heutiges Wörterbuch an. Die Oberfläche zeigt eine plausible Beschreibung, die zum damaligen Versuch aber nicht passt. Hat das System den ursprünglichen Kontext verworfen, lässt sich der Fehler der Darstellung später kaum noch vom Fehler des Geräts unterscheiden.

Die Migration sollte deshalb eine erneute Interpretation bekannter Versuchsdaten einschließen. Ein zweiter Test betrifft den Rücksprung auf einen alten Softwarestand: Verstehen die verbleibenden Gegenstellen und die Bereitschaftsorganisation dessen Meldungen noch richtig? Ein startfähiges Notfallabbild beantwortet diese Frage nicht.

Historische Lesbarkeit und aktive Altunterstützung müssen getrennt bleiben. Ein autorisiertes Archiv kann mit dem passenden Wörterbuch lesbar sein, während die alte experimentelle Bedeutung im laufenden Netz nicht mehr gesendet oder angenommen wird. Die Vergangenheit erklären zu können verlangt nicht, sie unbegrenzt weiterzubetreiben.

Prüfverfahren bleiben Prüfverfahren

Daneben stellt RFC 9756 die aufgeführten PCEP-Register von Standards Action auf IETF Review um. Nach RFC 8126 erlaubt IETF Review unterschiedliche RFC-Typen im IETF-Stream, während Standards Action auf Standards Track und Best Current Practice begrenzt ist. Die Prüfung auf Grundlage des IETF-Konsenses bleibt erhalten.

Das ist weder ein Verfahren nach Eingangsreihenfolge noch die Zulassung jedes beliebigen RFC-Streams. Die Arbeitsgruppe erwog engere Regeln für knappe Flag-Felder, hielt jedoch die Prüfverfahren für ausreichend gegen leichtfertige Belegung. Diese dokumentierte Abwägung belegt keine tatsächlich eingetretene Knappheit oder missbräuchliche Nutzung.

Auch bei unbekannten Fehlern ist eine vorschnelle Schlussfolgerung unangebracht. RFC 9756 nennt bei einem unbekannten Wert unter einem erkannten experimentellen Typ mehrere mögliche Ursachen: fehlerhafte Implementierung, nicht synchronisierte Werte oder parallele Experimente. Protokollierung und mögliches Schließen der Sitzung werden beschrieben; ein ausnahmsloses Gebot, jede PCEP-Fehlermeldung mit einem Sitzungsabbruch zu beantworten, entsteht nicht.

RFC 5440 behandelt unterschiedliche Bedingungen unterschiedlich, etwa durch Abbruch einer Anfrage oder Erhalt einer bestehenden Sitzung in einem bestimmten Fall. Eine offene Verbindung ist deshalb ebenso wenig ein vollständiger Bedeutungsnachweis wie ein Abbruch ein Beweis für eine Kollision.

Die analytische Haltung folgt Lu Hengs Plädoyer für Wirklichkeitsbeschreibung statt Interessenwerbung. Die Quellen belegen Mechanismen und Grenzen, keine Herstellerverbreitung, gemessenen Kosten oder konkreten Störungen. Gerade diese Begrenzung macht sichtbar, welche Nachweise ein Betreiber selbst beschaffen muss.