Résumé

  • La révision 17 de draft-ietf-pce-flexible-grid a été enregistrée le 13 septembre 2026, alors que le texte restait en évaluation par l’IESG pour le statut Proposed Standard et inscrit à la téléconférence du 17 septembre.
  • La révision 16 demandait deux nouvelles erreurs sous le type PCEP 24, qu’elle appelait Routing Problem; le registre IANA attribue déjà ce numéro à LSP instantiation error.
  • À la suite d’un DISCUSS d’un directeur de zone, le nouveau texte supprime les deux règles de réponse et la demande d’attribution correspondante. Il conserve un nouveau type distinct pour l’impossibilité de calculer une RSA Flexi-Grid.
  • Écarter la collision corrige le registre, mais retire aussi deux signaux observables. Une mise en œuvre doit donc tracer les suppressions, la version et le sens réellement émis.

Un numéro douanier ne peut pas désigner deux marchandises

Un code de protocole fonctionne comme une nomenclature douanière. L’octet est bref; son sens vient du registre, du message qui le porte et de la règle qui déclenche son émission. Si une notice locale rebaptise un numéro déjà occupé, deux systèmes conformes à des textes différents peuvent lire le même paquet et raconter deux événements.

C’est la faille de gouvernance rendue visible par la révision 16 de PCEP Extension for Flexible Grid Networks. Le projet permet à un client de calcul de chemin, PCC, de demander à un PCE une route et une tranche de fréquences dans un réseau optique à grille flexible. Parmi les paramètres figurent la symétrie et une méthode d’attribution telle que First-Fit ou Random.

Pour une symétrie ou une méthode non prise en charge, la révision 16 prescrivait un PathErr, code 24 Routing Problem, assorti de deux nouveaux sous-codes. Sa section 9.9 demandait ensuite à l’IANA de les inscrire sous l’Error-Type 24 de PCEP. Or le registre PCEP de l’IANA réserve déjà le type 24 à LSP instantiation error, conformément à RFC 8281. Et RFC 5440 appelle le message d’erreur PCEP PCErr, avec des champs Error-Type et Error-value. PathErr et Routing Problem relèvent du vocabulaire RSVP-TE.

Le 9 septembre, Gunter Van de Velde, directeur de la zone Routage, a consigné cette contradiction dans un DISCUSS. L’historique Datatracker montre qu’il ne critiquait pas seulement un mot: le numéro 24 ne pouvait pas être redéfini. Son DISCUSS soulevait aussi le conteneur et le format du Spectrum Allocation TLV, ainsi que la valeur zéro et la politique des futures attributions. Mohamed Boucadair a déposé un autre DISCUSS sur les exceptions de politique, les longueurs, l’analyse des liens, la découverte de capacité et les politiques IANA.

Le nouveau texte efface, il ne renumérote pas

La révision 17 répond à la collision par une opération nette. Le paragraphe qui imposait les deux PathErr disparaît. La section 9.9 et son tableau d’attribution disparaissent également. La comparaison officielle ne montre aucun déplacement de ces deux erreurs vers un autre type.

Le projet garde toutefois deux autres formes d’échec. Il demande un nouveau type, encore sans numéro, Flexi-Grid RSA Error, dont la valeur 1 signifie que le calcul RSA n’est pas pris en charge; la valeur 0 est désormais explicitement Unassigned. Un bit distinct dans NO-PATH-VECTOR indique qu’aucun chemin ne satisfait toutes les contraintes spectrales. Incapacité de calcul, absence de chemin admissible et refus d’un attribut demandé sont trois diagnostics différents. Le passage de la révision 16 à 17 retire le troisième signal explicite sans fusionner officiellement ces cas.

D’autres corrections ont une portée d’implémentation. La longueur du Frequency Slot Selection TLV doit être quatre. L’indice de fréquence n peut être positif, négatif ou nul. Le retour d’un Label Set reste obligatoire sauf erreur de politique ou de validation. Une plage inclusive contient exactement deux enregistrements d’identifiants de lien. Le texte reprend le nom ERO Hop Attributes subobject de RFC 7570 et ajoute RFC 9916 à ses références de sécurité PCEP sur TLS.

Ces modifications ne prouvent pas que tous les points sont clos. Le DISCUSS demandait notamment des règles de placement, d’ordre, d’association, de modification et de taille pour le TLV dans l’ERO. Corriger un nom de conteneur ne suffit pas à démontrer que cette chaîne d’exigences est complète. La conclusion vérifiable est plus modeste: le conflit autour du type 24 a disparu du texte et l’état de revue IANA est passé de IANA OK - Actions Needed à Version Changed - Review Needed.

La date du vote reste au futur

Le dossier Datatracker qualifie le texte de document du groupe PCE, soumis à l’IESG pour Proposed Standard. L’API du document horodate la révision à 09:57:08 UTC le 13 septembre. Elle reste en IESG Evaluation; la téléconférence du 17 septembre n’a pas encore eu lieu. Publier une version n’efface pas automatiquement un DISCUSS, ne termine pas la revue IANA et n’attribue aucun numéro.

Le retour de l’IANA à l’état «version changée, revue nécessaire» n’est pas un rejet. Il indique que les actions préparées doivent être comparées au nouveau texte. RFC 8126 définit les politiques d’enregistrement possibles; il appartient encore au processus de décider lesquelles gouvernent les plages nouvelles.

Un autre changement illustre la différence entre explication et capacité. La version 16 justifiait l’absence d’une nouvelle annonce PCEP OPEN par une approche fondée sur l’erreur, tout en renvoyant aux mécanismes de découverte OSPF et IS-IS de RFC 5088 et RFC 5089. La version 17 supprime cette justification, mais conserve la possibilité d’annoncer la capacité RSA par découverte. Cela clarifie le texte; cela ne mesure aucun déploiement.

L’appel final de l’IETF reliait aussi la déclaration IPR 3053. C’est un avis inscrit au dossier, non une conclusion sur la validité d’un brevet, son caractère essentiel, une contrefaçon, le besoin d’une licence ou son prix.

Un reçu pour le registre et le fil

Pour chaque diagnostic ajouté, déplacé ou supprimé, un reçu minimal devrait conserver l’ancien quintuplet — protocole, message, type, valeur, condition —, la ligne occupée du registre, l’objection qui a motivé le changement, puis le nouveau quintuplet ou la suppression explicite. Il devrait y joindre les empreintes des révisions, la version logicielle, un test sur paquet, l’état IANA, l’état du ballot et la date de mise en service.

Cette proposition est la mienne, pas une règle de l’IETF. Elle applique la discipline du Policy Mirror de Heng Lu: une politique réelle associe texte courant, copie déployée et chemin d’exécution. Une spécification initiale minimale peut normaliser ce reçu sans dicter la politique locale. L’exigence de réalité plutôt que plaidoyer empêche de transformer un diff en prétendue preuve d’un incident.

Aucune panne d’interopérabilité n’est établie ici. Aucun paquet public ne montre l’usage des erreurs supprimées. Le fait nouveau est plus précis: le contrôle institutionnel a repéré une collision avant publication et le contrat proposé a changé.

Sources