Zusammenfassung

  • draft-ietf-pce-flexible-grid-17 erschien am 13. September 2026. Das Dokument blieb in der IESG Evaluation als Proposed Standard und auf der Tagesordnung für den Telechat am 17. September.
  • Revision 16 beantragte zwei Werte unter PCEP Error-Type 24 und bezeichnete diesen als Routing Problem; im gültigen IANA-Register steht 24 für LSP instantiation error.
  • Ein DISCUSS wies darauf hin, dass PathErr und Error Code zur RSVP-TE-Terminologie gehören. Revision 17 löschte beide Antwortregeln und den Registrierungsantrag, behielt aber einen eigenen neuen Fehlertyp für nicht unterstützte RSA-Berechnung.
  • Die Korrektur schützt den Namensraum. Zugleich verschwinden zwei beobachtbare Signale. Deshalb müssen Umstellungen die Entwurfsversion und das Drahtverhalten gemeinsam dokumentieren.

Zwei Sicherungen mit derselben Nummer

In einem Schaltschrank darf Sicherung 24 nicht gleichzeitig für eine Pumpe und einen Signalkreis stehen. Ein zweiter Aufkleber beseitigt die erste Verdrahtung nicht. Wer nur die Nummer im Störungsprotokoll sieht, könnte sonst den falschen Stromkreis abschalten.

Genau diese Art von Mehrdeutigkeit enthielt Revision 16 von PCEP Extension for Flexible Grid Networks. Der Entwurf erweitert PCEP, damit ein Path Computation Client bei einem Path Computation Element Route und Frequenzslot in einem Flexi-Grid-Netz anfordern kann. Dabei lassen sich Symmetrie und ein Auswahlverfahren wie First-Fit oder Random vorgeben.

Unterstützte ein PCE die Symmetrie oder Methode nicht, sollte es laut Revision 16 ein PathErr mit Error Code 24, Routing Problem, und einem von zwei neuen Untercodes erzeugen. Abschnitt 9.9 beantragte diese Werte anschließend bei IANA unter dem bestehenden PCEP Error-Type 24.

Das IANA-PCEP-Register weist 24 jedoch bereits als LSP instantiation error gemäß RFC 8281 aus. Die PCEP-Basisspezifikation RFC 5440 nennt die Fehlermeldung PCErr und ihre Felder Error-Type sowie Error-value. PathErr, Error Code und Routing Problem stammen aus RSVP-TE. Der Text vermischte somit nicht bloß Begriffe, sondern die Semantik zweier Protokolle in einem belegten Zahlenraum.

Am 9. September erhob Routing Area Director Gunter Van de Velde deshalb einen formellen DISCUSS. Die Datatracker-Historie hält außerdem Fragen zum Format, Container und Ort des Spectrum Allocation TLV sowie zum Wert null und zur künftigen Zuteilung fest. Mohamed Boucadair stellte in einem weiteren DISCUSS Fragen zu Policy-Ausnahmen, fester Länge, Link-Identifiern, Discovery und IANA-Policy. Ein DISCUSS verlangt Bearbeitung; er ist keine Vorhersage einer Ablehnung.

Der neue Entwurf weist keinen Ersatzplatz aus

Revision 17 entfernt den ganzen Absatz mit den beiden PathErr-Antworten. Auch Abschnitt 9.9 samt Zuteilungstabelle entfällt. Im offiziellen Vergleich ist keine Verlagerung auf eine neue Nummer erkennbar. Die zwei spezialisierten Diagnosen sind im aktuellen Text nicht mehr definiert.

Andere Fehlersignale bleiben getrennt. Der Entwurf beantragt weiterhin einen neuen, noch unnummerierten Flexi-Grid RSA Error; Error-value 1 bedeutet RSA computation not supported, und Revision 17 ergänzt den Wert 0 als Unassigned. Ein eigenes NO-PATH-VECTOR-Bit sagt, dass kein Pfad alle Spektrumsvorgaben erfüllt. Fehlende RSA-Fähigkeit, kein zulässiger Pfad und ein nicht unterstütztes Einzelattribut sind verschiedene Zustände.

Weitere Änderungen sind unmittelbar prüfbar. Die Länge des Frequency Slot Selection TLV muss vier sein. Der Frequenzindex n darf positiv, negativ oder null sein. Ein Label Set ist nur ohne Policy- oder Validierungsfehler zwingend zurückzugeben. Eine Inclusive Range enthält genau zwei Link-Identifier-Datensätze. Der Text verwendet den Namen ERO Hop Attributes subobject aus RFC 7570 und ergänzt RFC 9916 zur TLS-Absicherung von PCEP.

Daraus folgt nicht, dass sämtliche DISCUSS-Punkte erledigt sind. Gefordert waren auch Regeln für zulässige Platzierung, Reihenfolge, Zuordnung, Änderung und Größenlimit des TLV. Eine korrigierte Containerbezeichnung ist kein Abschlussnachweis. Belegt sind die Entfernung der Type-24-Kollision und der Wechsel der IANA-Prüfung von IANA OK - Actions Needed zu Version Changed - Review Needed.

Der Telechat ist noch ein Termin

Der Datatracker-Eintrag führt das Dokument als Arbeit der PCE Working Group, die dem IESG als Proposed Standard vorliegt. Die API datiert Revision 17 auf den 13. September, 09:57:08 UTC. Der Status blieb IESG Evaluation; der Telechat am 17. September lag noch in der Zukunft. Ein Upload hebt keinen DISCUSS automatisch auf, genehmigt kein Dokument und vergibt keine Nummern.

Auch der neue IANA-Status bedeutet keine Ablehnung. Die geänderten Aktionen müssen erneut gegen das Register geprüft werden. RFC 8126 definiert Registrierungsverfahren, doch die Wahl der Policy für neue Bereiche bleibt Teil des Standardisierungsentscheids.

Die Discovery-Passage zeigt denselben Grenzfall. Revision 16 begründete den Verzicht auf eine neue PCEP-OPEN-Capability mit einem fehlerbasierten Ansatz und verwies zugleich auf OSPF- und IS-IS-Discovery nach RFC 5088 und RFC 5089. Revision 17 streicht die Begründung, lässt aber die mögliche Anzeige der Flexi-Grid-RSA-Fähigkeit per Discovery stehen. Das ist eine Textkorrektur, kein Nachweis über Netze im Betrieb.

Der IETF Last Call nannte außerdem die IPR-Offenlegung 3053. Sie ist eine Verfahrensnotiz und hier kein Befund zu Gültigkeit, Wesentlichkeit, Verletzung, Lizenzbedarf, Preis oder Freedom to Operate.

Änderungsbeleg für Register und Paket

Bei jeder hinzugefügten, verschobenen oder entfernten Diagnose sollte ein Mindestbeleg das alte Tupel aus Protokoll, Nachricht, Error-Type, Error-value und Bedingung sichern. Dazu gehören die damals gültige Registerzeile, der Review-Befund, das neue Tupel oder die ausdrückliche Löschung, ferner Entwurfshashes, Softwareversion, Pakettest, IANA- und Ballot-Status sowie Aktivierungsdatum.

Das ist mein redaktioneller Vorschlag, keine IETF-Vorschrift. Heng Lus Policy Mirror verbindet gültige Regel, verteilte Kopie und Ausführungspfad. Eine minimale Anfangsspezifikation kann nur diesen Beleg vereinheitlichen, ohne Betreiberpolitik zu zentralisieren. Reality, Not Advocacy trennt den dokumentierten Textwechsel von einer nicht belegten Betriebsstörung.

Es gibt hier keinen öffentlichen Interoperabilitätsausfall und keinen Paketmitschnitt der gelöschten Fehler. Die Nachricht ist enger: Das Prüfverfahren fand vor der Freigabe eine Kollision und änderte den vorgeschlagenen Diagnosevertrag.

Quellen