Résumé

  • Publiée le 11 septembre 2026, la révision 14 de draft-ietf-mpls-mna-ioam ajoute une règle pour le nœud MPLS dont la technique d’équilibrage n’est pas connue.
  • Pour un flux désigné par Flow ID MNA, la portion de 19 bits du Sequence Number MNA commençant au bit 1 de la LSE doit rester immuable si la pile d’étiquettes participe à l’équilibrage — et désormais aussi en cas d’incertitude.
  • Le projet exclut de son périmètre les mécanismes servant à découvrir la technique d’équilibrage. La règle neutralise donc une source possible de variation, mais ne démontre pas la stabilité du trajet mesuré.
  • Avant de comparer des observations IOAM-DEX, l’exploitant devrait conserver un reçu local indiquant l’hypothèse de hachage, sa preuve et le contexte de capture.

Le troisième cas manquait

La version précédente posait une alternative confortable tant que l’équipement était bien connu. Si l’on savait que le nœud utilisait des informations de la pile d’étiquettes pour répartir les flux, une portion de 19 bits du numéro de séquence devait rester identique pour un même Flow ID. Si l’on savait qu’il recourait à une autre technique, tous les bits du numéro pouvaient changer.

Mais une grande partie de l’exploitation réelle habite une troisième case : comportement propriétaire mal documenté, génération différente de silicium, configuration héritée, ou simple absence de preuve. La comparaison officielle entre les révisions 13 et 14 montre l’ajout décisif. Quand la technique employée par le nœud n’est pas connue, la même portion de 19 bits, à partir du bit 1 de la LSE, doit demeurer immuable pour le flux identifié par Flow ID MNA.

Ce choix fait de l’incertitude une contrainte, et non une permission. Il évite qu’un compteur qui évolue paquet après paquet injecte sans nécessité de l’entropie dans un calcul susceptible de lire la pile MPLS. Le projet précise aussitôt qu’il ne définit aucun mécanisme permettant d’apprendre la technique d’équilibrage des nœuds. La norme proposée choisit un défaut prudent ; elle ne produit pas la connaissance qui permettrait de l’abandonner.

Un champ d’observation placé dans la pile

IOAM-DEX sert à exporter directement des informations opérationnelles. RFC 9326 prévoit notamment un Flow ID pour rapprocher les exportations d’un même flux et un numéro de séquence qui débute normalement à zéro puis augmente d’une unité à chaque paquet DEX du flux. La méthode d’allocation du Flow ID n’y est pas imposée.

Dans draft-ietf-mpls-mna-ioam-14, les variantes MNA de ces deux champs sont optionnelles. Chacune occupe une LSE de format D complète de 32 bits. Une fois retranchés le bit initial fixé et le bit S de fin de pile MPLS, la valeur utile compte 30 bits. Cette disposition rapproche le compteur du plan de transfert : si un équipement hache la pile pour maintenir les paquets d’un flux sur un chemin, faire varier tous les bits peut modifier l’entrée du hachage.

La révision 14 clarifie aussi que la LSE complète du Flow ID ou du Sequence Number doit être omise lorsque le drapeau de présence correspondant est à zéro. Pour le numéro de bloc utilisé par le marquage alterné dans l’en-tête post-pile, l’exigence devient impérative : si le marquage alterné n’est pas utilisé, la valeur doit être zéro. Plusieurs assemblages interdits d’actions en pile et après la pile sont qualifiés de malformés et doivent provoquer l’abandon du paquet.

Ces règles s’insèrent dans l’architecture IOAM de RFC 9197, qui limite déjà l’usage à un domaine contrôlé et demande de considérer les effets de l’ECMP, ainsi que dans le cadre MNA de RFC 9789 et la solution de base de RFC 9994. Le projet s’appuie également sur la spécification encore évolutive de l’en-tête MNA après la pile et sur des champs IOAM existants, dont ceux suivis dans le registre IANA Trace-Type.

Ce que les 19 bits ne prouvent pas

Une portion stable peut empêcher le numéro de séquence de déplacer lui-même un paquet entre chemins. Elle ne révèle pas les entrées réelles du hachage, la profondeur d’étiquettes inspectée, l’existence d’un autre nœud qui prend une décision différente, ni l’effet d’une mise à jour logicielle. Elle ne garantit pas non plus que le trafic instrumenté représente exactement les paquets ordinaires auxquels on veut le comparer.

Le Flow ID fournit une clé de rapprochement, pas une attestation universelle de classe de trafic. Deux exportations portant le même identifiant peuvent encore provenir d’un chemin dont une portion a varié ; inversement, une discontinuité de séquence peut provenir de l’exportation plutôt que du transfert. Le document ne contient ni capture de paquets, ni test d’interopérabilité, ni mesure de coût qui permettrait de lever ces ambiguïtés.

La portée de confiance reste stricte. Le texte destine IOAM et IOAM-DEX à un seul domaine administratif de confiance. Les nœuds de bord doivent filtrer les paquets portant ces actions lorsqu’ils arrivent d’un autre domaine ou d’une source non fiable. Les données auxiliaires peuvent circuler en clair et ne doivent pas être tenues pour intègres sans protection supplémentaire.

Enfin, le statut institutionnel ne doit pas être gonflé. La fiche Datatracker présente un Internet-Draft actif du groupe MPLS, destiné au niveau Proposed Standard. L’état du groupe est « Submitted to IESG for Publication » et celui de l’IESG « Publication Requested » ; l’historique retrace les versions. Les opcodes sollicités restent TBA. Une révision publiée n’est ni une allocation IANA, ni une approbation, ni un déploiement.

Sources