Résumé

  • La RFC 9863 définit l’annonce de la capacité de couleur et le transport d’une valeur de couleur sur 32 bits dans un objet LSP PCEP.
  • Une valeur peut décrire un attribut de chemin. Elle ne démontre pas la politique locale qui lui donne un sens, le rattachement d’un service, ni la performance obtenue.

Le langage de la couleur est séduisant parce qu’il semble résumer une intention opérationnelle. La RFC mentionne l’exemple d’un tunnel optimisé pour une faible latence. Or l’objet normalisé est un entier non signé de 32 bits. Il transporte une étiquette, pas une série de mesures, pas une décision de placement de trafic et pas une garantie offerte à un client. La différence n’est pas sémantique seulement : elle détermine quelles affirmations peuvent être auditées et lesquelles exigent encore des preuves.

La première preuve est étroite. Un PCE ou un PCC déclare la capacité COLOR par le bit 20 du STATEFUL-PCE-CAPABILITY TLV. Une fois cette capacité annoncée, un COLOR TLV de type 67 peut être porté dans l’objet LSP. Il ne doit pas être envoyé à un pair qui n’a pas annoncé la capacité, et les doublons ne produisent pas plusieurs interprétations : seul le premier est traité. Cette séquence établit une compatibilité de fonction et une discipline de message. Elle ne crée pas une classe de service commune.

Le cas des SR Policy Associations montre pourquoi il faut résister aux raccourcis. Pour les chemins SR établis avec le mécanisme de la RFC 9862, la couleur est déjà encodée dans l’association ; la couleur dans l’association l’emporte et un COLOR TLV porté par l’objet LSP est ignoré. La norme tranche une collision de représentation. Elle ne tranche pas le choix d’un service, la règle commerciale d’un opérateur ou le comportement effectif du plan de données.

Les erreurs PCEP sont également bornées. Un PCC qui ne peut respecter une couleur reçue doit renvoyer Invalid Color. Des couleurs incompatibles dans le même groupe d’association de protection exigent un rejet Inconsistent Color. Ces retours prouvent quelque chose d’important : un contrôle de conformité a eu lieu pour une entrée précise. Une acceptation ne prouve que l’inverse limité — que cette entrée a passé ce contrôle. Elle ne prouve ni l’installation du chemin, ni son usage, ni son effet sur un flux.

La RFC laisse expressément les étapes suivantes à l’extérieur. Le mécanisme de mappage des services vers un chemin coloré est hors champ. Un PCC peut appliquer sa propre politique locale ; l’implémentation devrait permettre de configurer la capacité et l’affectation de couleur. L’opérateur peut lire l’état d’un chemin TE pour vérifier la couleur prévue. Mais la RFC n’ajoute pas de détection de vivacité et affirme que l’impact dépend du déploiement. Lire la bonne couleur ne revient donc pas à constater la bonne qualité de service.

Le risque de contrôle est visible dès que l’étiquette devient un argument d’assurance. Il faut conserver séparément l’identité et la protection du PCE, l’annonce de capacité, la valeur reçue, la politique qui la définit, le choix de mappage, le chemin configuré, l’observation de données et la mesure de performance. Une console qui fond ces étapes dans un badge « faible latence » remplace une chaîne de responsabilité par une couleur.

La distinction rejoint Heng Lu : une spécification publiée est un artefact de coordination, non une déclaration qui rend l’adoption réelle. La couche commune de RFC 9863 rend un attribut portable et vérifiable selon certaines règles. Le sens ultérieur, le déploiement et l’acceptation restent locaux. La valeur de la norme tient à cette limite, non à une prétention de résultat qu’elle n’a pas formulée.

Sources