Summary

  • RFC 9933 permet de signaler dans PCEP l’algorithme associé à un SID et d’imposer une contrainte SR-Algorithm. Pour les valeurs 128 à 255, le numéro renvoie cependant à une Flexible Algorithm Definition choisie ailleurs, avec sa métrique, ses contraintes, ses participants et ses données topologiques.
  • La preuve utile n’est donc pas « le chemin a utilisé le numéro 130 », mais « à cet instant, 130 s’est résolu en cette FAD gagnante, dans ce périmètre, avec cette sémantique et cette version des règles ». Un reçu de résolution peut conserver cette chaîne sans divulguer la topologie complète.

Le lendemain d’un incident, deux équipes ouvrent leurs journaux. L’équipe de transport montre que le chemin a été calculé avec SR-Algorithm 130. L’équipe de service produit une capture plus ancienne où figure exactement la même valeur. Chacun en déduit que la politique est restée stable et cherche la cause ailleurs.

Ce raisonnement peut être faux alors que les deux journaux sont exacts.

Entre les deux calculs, une annonce de définition plus prioritaire a pu gagner. Le type de métrique a pu changer. Un seuil de bande passante a pu être révisé. Une nouvelle règle d’élagage a pu exclure un lien dans le sens inverse. Un routeur incapable d’exécuter la nouvelle définition a pu cesser de participer. Aucun de ces changements n’oblige l’opérateur à abandonner le numéro 130.

Le numéro est un point d’accès à la politique, pas son empreinte.

RFC 9933 rend cette distinction particulièrement nette. Le texte normalise le transport d’un champ Algorithm dans les objets de route PCEP, la demande d’une contrainte SR-Algorithm et plusieurs métriques de chemin. Il décrit soigneusement la négociation de capacité et les erreurs. Pour les Flexible Algorithms, il confie pourtant le calcul à un état de politique acquis par d’autres mécanismes.

Il n’y a là aucune lacune d’interopérabilité. C’est le prix raisonnable d’une abstraction compacte. Mais une institution qui transforme cette abstraction en preuve de conformité doit ajouter la provenance que le paquet n’a pas vocation à porter.

Ce que certifie réellement l’échange PCEP

Publié en juillet 2026 sur la voie Standards Track de l’IETF, RFC 9933 met à jour les extensions PCEP consacrées à Segment Routing pour MPLS et IPv6. Il autorise l’association d’un SR-Algorithm aux sous-objets SR-ERO et SR-RRO, ainsi qu’à leurs équivalents SRv6. Il introduit aussi un TLV SR-Algorithm dans l’objet LSPA pour demander une contrainte de calcul.

Le mécanisme est borné. Les deux interlocuteurs doivent avoir annoncé la capacité correspondante. Une utilisation sans capacité négociée déclenche une erreur d’opération invalide. Une longueur incohérente rend l’objet mal formé. Un SID inconnu produit une erreur définie. L’impossibilité de satisfaire la combinaison de contraintes doit aboutir à un ERO vide ou à NO-PATH, non à un chemin inventé en silence.

Ces garanties répondent à quatre questions : les pairs comprennent-ils l’extension, l’objet est-il bien formé, la valeur demandée a-t-elle été prise en compte selon les règles, et le résultat peut-il être représenté ? Elles ne répondent pas à une cinquième : quelle politique institutionnelle la valeur désignait-elle ce jour-là ?

Pour 0 et 1, le registre public nomme respectivement SPF et Strict-SPF. Pour 2 à 127, l’espace reste sous normalisation. La plage 128–255 est réservée aux Flexible Algorithms. Dans cette plage, le sens n’est pas contenu dans le nombre ; il vient d’une configuration annoncée dans le domaine.

Un outil d’observabilité qui affiche « 130 » sans autre contexte montre donc un fait vrai mais incomplet. C’est exactement le type de miroir technique qui peut devenir dangereux : fidèle à l’état visible, muet sur l’autorité et la décision qui lui donnent sens.

La FAD gagnante peut changer sans renumérotation

RFC 9350 appelle Flexible Algorithm Definition l’ensemble formé d’un type de calcul, d’un type de métrique et de contraintes. Une valeur comprise entre 128 et 255 est associée par configuration à cet ensemble.

Plusieurs routeurs peuvent annoncer une définition pour le même numéro. Le protocole impose alors une sélection commune. On retient d’abord la priorité numérique la plus élevée. En cas d’égalité, l’annonce provenant du plus grand System-ID IS-IS ou Router ID OSPF l’emporte. Le texte nomme ce résultat la « winning FAD ».

La cohérence distribuée est ainsi assurée dans le périmètre d’annonce. Mais, pour l’audit, le numéro ne suffit plus. Il faut connaître la liste des annonces candidates, leur priorité, leur origine, le départage et la définition finalement retenue. Une nouvelle annonce de priorité supérieure peut substituer une politique à une autre sans toucher au champ SR-Algorithm des demandes.

Le détail le plus révélateur est que l’émetteur d’une FAD n’a pas besoin de participer lui-même à l’algorithme. Les récepteurs doivent considérer son annonce. Le pouvoir de définir et le fait d’exécuter sont donc séparables. Cette séparation est utile pour centraliser la politique, mais elle doit être visible dans la matrice de responsabilité.

RFC 9350 impose qu’un nœud incapable de prendre en charge un élément de la définition gagnante cesse de participer et retire l’état de transfert correspondant. Une modification peut entraîner recalcul et reconvergence à l’échelle du réseau. La norme protège l’intégrité du nouvel état ; elle ne fabrique pas l’autorisation humaine de la modification.

Le périmètre fait partie du sens

La FAD est sélectionnée par zone. RFC 9350 précise qu’un même numéro n’a pas à recevoir une définition identique partout. Une zone peut l’utiliser pour minimiser le délai, une autre pour privilégier la bande passante.

Ce choix permet une politique locale adaptée. Il rend aussi trompeur tout inventaire global qui déduirait l’identité de sens de l’identité de valeur. La bonne clé n’est pas « 130 », mais au minimum « 130 dans telle zone, à telle époque de politique ».

La situation ressemble à un numéro d’article de loi détaché du pays et de la version du code. Le numéro n’est pas erroné ; c’est la citation qui est incomplète. Dans un réseau multi-zone, la portée d’annonce, le niveau IS-IS ou la zone OSPF sont des éléments sémantiques, pas de simples colonnes techniques.

RFC 9933 laisse hors de son périmètre le cas où un calcul de bout en bout utiliserait des contraintes SR-Algorithm différentes, ou des FAD gagnantes aux métriques et contraintes différentes, selon les domaines traversés. Cette limite raisonnable devrait interdire aux tableaux de bord d’aplatir ces domaines sous une couleur unique.

La gouvernance ne doit pas supprimer la variation locale. Elle doit empêcher qu’une variation légitime soit ensuite racontée comme une politique universelle et stable.

La requête est volontairement incomplète

Pour une valeur de Flexible Algorithm, RFC 9933 demande au PCE de s’appuyer sur sa Traffic Engineering Database. Celle-ci est censée contenir les FAD, la participation des nœuds et les attributs de lien propres à l’application, appris notamment par les extensions IGP ou par BGP-LS décrit dans RFC 9552.

La requête PCEP n’est donc pas un paquet autonome que l’on pourrait rejouer à l’identique dans n’importe quel état du réseau. Elle est une instruction évaluée contre un environnement mouvant.

Le traitement de la métrique le montre bien. Pour une Flexible Algorithm, le PCE doit optimiser selon le type de métrique de la FAD. Si le PCC place une métrique d’optimisation dans le message, le PCE doit l’ignorer. Il combine les contraintes de la FAD et celles de la requête, mais le PCC ne doit pas recopier les contraintes de la FAD dans le message.

Cette factorisation évite la duplication et les contradictions. Elle produit aussi un piège documentaire : archiver la requête et la réponse ne suffit pas pour rejouer le raisonnement. Il faut l’état de résolution qui se trouvait dans le TED, ainsi que les versions de politique qui l’ont structuré.

Un ERO valide prouve le résultat transmis. Il ne prouve pas, à lui seul, que le futur auditeur dispose encore du même univers de calcul.

Les métriques locales sont des choix économiques

RFC 9843 élargit les FAD avec des contraintes de bande passante et de délai, une méthode de calcul automatique de métrique et des métriques génériques. Les types 128–255 peuvent recevoir un sens défini localement par l’opérateur.

Cette liberté évite de normaliser trop tôt chaque besoin. Une organisation peut représenter un coût financier, la gigue, une consommation énergétique ou un risque contractuel. Mais « metric-type 130 » n’est intelligible qu’avec le dictionnaire local qui explique l’unité, la formule, la source et la date d’effet. RFC 9843 demande d’ailleurs aux domaines de donner le même sens à la valeur lorsqu’une métrique locale traverse des zones ou des niveaux.

Même la métrique de bande passante standardisée contient une politique. Une valeur explicitement annoncée pour un lien peut l’emporter sur le calcul automatique. En son absence, la FAD gagnante peut fournir une bande passante de référence ou des seuils. Modifier ces paramètres centraux modifie le classement des chemins sans changer le numéro SR-Algorithm.

La politique de routage ne se réduit donc pas à « minimiser un nombre ». Elle inclut la décision de ce que le nombre mesure. Attribuer un poids à un coût, à un délai ou à une marge de capacité distribue du trafic, du risque et parfois des dépenses entre infrastructures.

Pour reconstituer une décision, l’auditeur doit conserver le dictionnaire de métriques. Pour un type local : propriétaire, unité, normalisation, version et portée. Pour une dérivation automatique : méthode, paramètres, règle de priorité et données d’entrée. L’arithmétique sans sémantique reproduit un résultat mais n’explique pas la décision.

Les règles d’élagage forment un évaluateur versionné

Une FAD ne se contente pas de classer les liens. Elle élimine ceux qui ne satisfont pas ses contraintes. RFC 9917 a créé le registre IANA « IGP Flex-Algorithm Path Computation Rules ».

Le registre IANA ordonne les tests : groupes administratifs exclus, SRLG, conditions include-any et include-all, métrique absente, limites de bande passante ou de délai, puis contraintes dans le sens inverse. Le registre relève de l’Expert Review et ne fixe pas de nombre maximal de règles.

Il faut donc versionner l’évaluateur, pas seulement ses entrées. Une nouvelle règle, un changement de logiciel PCE ou une capacité absente peuvent modifier l’ensemble des liens candidats. Deux calculs ayant le même numéro, la même FAD apparente et une topologie proche peuvent diverger parce que leur moteur de décision n’est pas identique.

RFC 9933 exige l’échec si la combinaison n’est pas prise en charge. C’est une protection essentielle. Pour comprendre un NO-PATH, il faut néanmoins savoir quelle règle a éliminé quel candidat et quelle donnée a déclenché cette règle. « Aucune route » est un résultat ; ce n’est pas encore une explication.

Les systèmes automatisés oublient souvent cet état intermédiaire. Ils conservent la demande et la réponse, mais pas la version du décideur. Or une décision reproductible repose sur trois archives : les faits, la politique et l’évaluateur.

Algorithme, métrique et fonction objectif restent distincts

RFC 5541 définit les fonctions objectif dans PCEP. Le PCC peut en demander une comme obligatoire ou souhaitée. Lorsqu’elle est seulement souhaitée, le PCE peut en appliquer une autre selon ses capacités et sa politique locale.

RFC 9933 dit explicitement que SR-Algorithm ne remplace pas la fonction objectif. Le type de métrique constitue encore une autre couche. Une preuve intelligible doit donc garder les distinctions : le numéro sélectionne une famille et, pour une Flexible Algorithm, une définition ; la FAD apporte calcul, métrique et contraintes ; la fonction objectif classe les chemins valides ; le TED fournit les faits courants.

RFC 9753 traite en outre les objets PCEP dont le traitement peut être optionnel. Lorsque les deux pairs prennent en charge le mécanisme, un objet peut être ignoré et cette disposition doit être signalée. Une contrainte relaxée n’a pas le même statut qu’une contrainte satisfaite. Le reçu d’audit doit conserver cette différence.

RFC 9826 fournit un modèle YANG pour les entités, pairs, sessions et statistiques PCEP. RFC 9933 demande que l’opérateur puisse voir les nouvelles capacités, les FAD et les nœuds participants. La visibilité rend la preuve possible ; elle ne garantit pas que l’historique sera conservé.

TLS protège le transport, pas la durée du sens

RFC 9933 recommande TLS pour la session PCEP. RFC 9916 actualise l’usage de TLS dans PCEPS. Ces protections sont indispensables contre la modification des messages et l’usurpation des pairs.

Une session authentifiée peut cependant transporter une demande qui se résout contre une politique nouvellement activée. TLS ne connaît ni le ticket de changement, ni l’autorité qui a approuvé une priorité plus élevée, ni la date à laquelle une définition d’urgence devait expirer.

L’intégrité cryptographique répond à « qui a envoyé ces octets et ont-ils changé ? ». La provenance de politique répond à « pourquoi ces octets ont-ils déclenché cette décision-là ? ». Confondre les deux revient à demander à une enveloppe scellée de justifier la règle appliquée à son contenu.

Le reçu de résolution de politique

Il serait disproportionné de transporter tout le dossier de gouvernance dans PCEP. La topologie, les coûts et certaines exclusions sont sensibles. Le protocole doit rester rapide et interopérable. La pièce manquante peut être conservée à côté du flux opérationnel.

Un reçu de résolution associerait à chaque calcul significatif : l’identité de la requête et des pairs ; l’heure et le périmètre ; le numéro SR-Algorithm ; la FAD normalisée et son empreinte ; l’annonce gagnante, sa priorité et le départage ; le dictionnaire de métrique ; la fonction objectif ; les contraintes directes et leur disposition ; la version ordonnée des règles d’élagage ; une empreinte du TED et de la participation ; le résultat et sa raison ; enfin le ticket, le rôle approbateur, la fenêtre d’activation et la condition de retour.

Le niveau partagé peut se limiter aux empreintes, versions, catégories de raison et responsables. Une équipe habilitée résout ensuite ces engagements vers les données protégées. Cette architecture ne promet pas la transparence totale. Elle organise une possibilité de contrôle.

Elle permet aussi de séparer un changement de faits d’un changement de règle. Une panne peut modifier le chemin sous politique constante. Une nouvelle FAD peut modifier le chemin à topologie comparable. Sans version des deux, l’organisation attribue facilement à l’infrastructure ce qui relevait d’une décision.

Sources