Résumé

  • RFC 9994 définit le sous-empilement d’actions réseau MPLS et les données auxiliaires associées ; l’encodage ne prouve pas que tous les nœuds puissent ou doivent agir.
  • La portée, la profondeur lisible, les capacités connues, la règle relative aux actions inconnues et le rôle du nœud séparent une action annoncée d’une action admise.
  • Une preuve exploitable relie l’encapsulation, la sélection de chemin, le traitement local et le résultat observé sans les confondre.

Le terme « action réseau » est volontairement puissant. Dans RFC 9994, il désigne des informations placées dans une pile de labels MPLS pour influencer un acheminement, transporter des éléments d’OAM ou réaliser une opération définie par l’utilisateur. Mais le document n’affirme pas qu’un paquet peut ordonner à tout routeur de l’accepter. Il décrit un NAS — Network Action Sub-Stack — et les conditions dans lesquelles des implémentations compatibles le lisent.

Le NAS commence par le label spécial MNA de valeur 4, suivi d’une entrée Format B contenant un premier opcode et les champs décrivant le sous-empilement. Des entrées Format C et D peuvent compléter l’ensemble. L’opcode n’est pas une consigne complète. Pour toute nouvelle action, la RFC exige une définition de format, de portée, de données auxiliaires, de procédure de traitement et d’interactions avec les autres actions. Sans ces éléments, un numéro enregistré ne dit pas encore quelle décision locale est justifiée.

Cette prudence est pratique. L’encapsulateur doit s’assurer que les nœuds de transit et de sortie peuvent traiter le NAS et que le paquet respecte le MTU du chemin. Il doit donc disposer d’informations sur les capacités MNA et la profondeur de labels lisible — des informations qui peuvent être configurées, gérées ou distribuées par des protocoles de contrôle, mais dont le mécanisme d’apprentissage reste hors du champ de RFC 9994. L’action décrite dans le paquet ne remplace ni cette connaissance, ni la sélection de chemin qui l’utilise.

Une portée ne remplace pas une capacité

Le champ IHS fixe une portée commune aux actions d’un même NAS. I2E réserve le traitement au nœud de sortie. HbH demande le traitement tout au long du chemin. Select ne vise que les nœuds particuliers qui exposent le NAS au sommet de pile. Pour combiner des portées, il faut des NAS distincts.

Ce sont des obligations de traitement pour les nœuds concernés et capables. Ce ne sont pas des attestations de déploiement. Une portée HbH ne démontre pas qu’un équipement intermédiaire possède la profondeur lisible requise, reconnaît l’opcode, a reçu une annonce de capacité exacte ou conserve une politique compatible. Elle précise ce que la solution attend d’un nœud qui traite effectivement le NAS ; elle ne transforme pas un réseau hétérogène en parc uniforme.

La règle pour une action inconnue refuse aussi la fiction d’un ordre universel. Le bit U impose soit de passer à l’action suivante, soit de supprimer le paquet. C’est une décision de repli déclarée dans l’encodage, pas une authentification, ni une permission inter-domaine, ni une preuve que l’opération attendue a été exécutée. Un chemin peut donc voir une même structure de paquet conduire à un traitement, un saut ou une perte conforme à la règle locale et au niveau de compréhension du nœud.

Les rôles rendent l’enquête plus précise. Le nœud encapsulant ajoute éventuellement des NAS selon sa politique et les capacités apprises. Le transit traite dans l’ordre et suit la règle U. Le pénultième nœud doit conserver le dernier NAS HbH ou I2E exposé pour que la sortie puisse le traiter. Le nœud de sortie retire tout NAS reçu. Lorsque l’effet annoncé n’apparaît pas, il faut donc demander : quelle action a été encodée, quelles capacités ont été utilisées pour calculer le chemin, qui a exposé le NAS, qui l’a reconnu, et quel résultat de sortie a été observé ?

Dire simplement que « l’action MPLS a été envoyée » répond à très peu de ces questions.

Les données auxiliaires ont leur propre risque. RFC 9994 explique que certains changements dans les bits de valeur de label peuvent modifier le calcul ECMP et désordonner les paquets d’un même flux. Les données mutables doivent alors éviter ces bits ; des placements alternatifs sont prévus. Cela n’est pas une promesse de performance, seulement une limite technique qui doit être vérifiée dans l’environnement réellement exploité.

La section de sécurité maintient le même réalisme : une action d’encapsulation peut affecter les nœuds du chemin, des actions définies localement peuvent être peu supervisées, des nœuds intermédiaires peuvent modifier les données, et les frontières administratives doivent pouvoir filtrer MNA avant un déploiement. Les compteurs recommandés aident à voir les NAS traités, les actions inconnues sautées ou perdues et les structures mal formées. Ils ne constituent pas, par eux-mêmes, un registre public de l’exécution.

La doctrine de Running-Code Primacy de Heng Lu aide à garder la hiérarchie correcte. La spécification commune fixe la compatibilité minimale. La vérité opérationnelle vient ensuite : capacité connue, admission locale, traitement du rôle, effet de transfert, puis résultat de service. Une étiquette ne devient pas un mandat parce qu’elle est élégamment normalisée.