Résumé

  • RFC 9961 adresse une instance d’arbre SR P2MP MPLS par Root, Tree-ID et Instance-ID ; il ne teste pas le chemin candidat comme totalité abstraite.
  • État actif, autres PTI, raccords unicast, aiguillage d’entrée, contexte de service et livraison utilisateur ont chacun besoin d’un reçu daté.

Imaginons une bascule préparée. Le contrôleur a construit une nouvelle topologie, le ping rejoint les feuilles demandées et le tableau de bord annonce que « la politique » est saine. Le trafic réel, lui, continue peut-être de suivre l’ancienne instance. Ce n’est pas une contradiction du protocole : c’est une confusion entre l’objet sondé et l’objet nommé dans le rapport.

RFC 9961 est un document IETF Standards Track publié en avril 2026. Il étend ping et traceroute MPLS aux politiques SR P2MP encapsulées en MPLS, pas à SRv6. Sa fiche RFC Editor et la recherche d’errata fixent le statut documentaire sans attester aucun déploiement.

La structure vient de RFC 9960. La politique est identifiée par <Root, Tree-ID> et possède un ou plusieurs chemins candidats. Chaque candidat porte des contraintes et objectifs ; il peut n’avoir aucune PTI si le calcul échoue, en avoir une en régime stable ou en contenir plusieurs pendant un make-before-break. Une seule PTI est active dans le candidat, et leurs topologies peuvent différer.

Le nouveau sous-TLV Target FEC Stack ajoute l’Instance-ID à la racine et au Tree-ID. RFC 9961 précise qu’il vise une PTI déterminée dans un CP déterminé, et non le CP lui-même. L’allocation correspondante figure au registre IANA MPLS LSP Ping. La précision de l’identifiant rend le résultat exploitable, mais interdit de l’étendre sans preuve.

Une PTI inactive peut répondre. Le RFC demande que chaque CP et chaque PTI associée puissent être testés séparément ; un nœud comprenant le Replication-SID traite la requête même si le couple n’est pas actif. C’est exactement ce qu’il faut pour qualifier une relève avant bascule. Mais un succès ne dit pas quelle PTI recevait le trafic utilisateur à cet instant.

Le périmètre des réponses compte autant. Les procédures de RFC 6425 et le cadre de détection de RFC 8029 sont réutilisés. La racine connaît les feuilles ; les routeurs de transit ne les connaissent souvent pas. Un sous-TLV visant l’adresse d’une feuille ne convient donc pas : un transit ne sait pas toujours s’il appartient à son chemin et peut se taire. Les identifiants de nœud peuvent aussi limiter volontairement les réponses. Une absence n’a de sens qu’avec la demande exacte.

Les segments de réplication non adjacents révèlent une autre coupure. L’OAM P2MP vérifie l’arbre de réplication ; un outil unicast distinct vérifie le chemin qui relie deux segments. La détection de panne de ce raccord est hors périmètre de RFC 9961. En traceroute, l’entrée du raccord doit utiliser Pipe Mode afin de préserver le TTL du test P2MP, suivant le modèle de RFC 3270.

RFC 9524 définit les Replication segments et RFC 9256 le modèle général de sélection des candidats SR. La chaîne probante devient alors visible : calcul du contrôleur, installation, sélection active, politique locale d’aiguillage, requête OAM, réponses bornées, test unicast, compteurs de trafic et reçu du service. Aucun maillon ne peut signer pour le suivant.

La primauté du code en fonctionnement de Heng Lu demande ce retour vers l’observation. Sa spécification initiale minimale justifie l’identifiant commun sans centraliser la décision, et ses couches de réalité empêchent le nom « politique » d’absorber instance et résultat.

Un bon rapport ne dit donc pas seulement « vert ». Il dit quelle racine, quel arbre, quelle instance, quel périmètre de réponse, quel mode TTL et quelle heure. Le reste doit encore répondre.