Résumé

  • Le RFC 9960 identifie une politique SR P2MP par une Racine et un Tree-ID, puis distingue les chemins candidats et les instances d’arbre. Cette identité décrit l’acheminement, pas le droit commercial ou institutionnel de recevoir le service.
  • Le RFC 9961 vise une PTI particulière dans un chemin candidat et observe son plan de données MPLS. Il précise que le test ne couvre pas le chemin candidat abstrait et qu’il ne s’applique pas à SRv6.
  • Un reçu d’audience multipoint devrait relier la décision d’adhésion à la politique, à la PTI, aux feuilles, à la génération du contrôleur, au périmètre du test et à la fin du make-before-break. C’est une proposition de Daniel Kade, non une exigence de l’IETF.

L’arbre sait où copier, pas pourquoi

La promesse du point-à-multipoint est économique au sens physique du terme. Au lieu d’expédier depuis l’entrée une copie complète à chaque destination, le réseau transporte un seul flux sur les portions communes, puis le réplique là où les chemins se séparent. Une Racine, des nœuds intermédiaires et des feuilles composent une topologie efficace.

Le RFC 9960, publié comme norme proposée de l’IETF, donne à cette topologie une structure contrôlable pour SR-MPLS et SRv6. La politique est nommée par le couple <Root, Tree-ID>. Elle contient l’ensemble des feuilles et un ou plusieurs chemins candidats. Chaque chemin peut produire une instance d’arbre P2MP, ou aucune si les contraintes ne peuvent être satisfaites.

Cette précision est indispensable à l’exploitation. Elle ne contient toutefois aucune sémantique d’abonnement. Une feuille peut représenter un site client, un nœud de distribution interne, un destinataire temporaire ou un équipement dont l’adresse vient d’être réattribuée. Le transport ne connaît pas la différence.

La liste des feuilles est donc une projection. En amont, une autre institution décide qui appartient au service : système contractuel, registre de rôles, annuaire de locataires, liste d’urgence ou décision humaine. En aval, le contrôleur transforme cette population en adresses et en segments de réplication. Si la projection est ancienne, le réseau peut exécuter parfaitement une décision qui n’est plus valable.

La stabilité du Tree-ID masque des changements réels

Une politique P2MP peut contenir plusieurs chemins candidats. La Racine choisit le chemin actif selon les règles de départage du RFC 9256. À l’intérieur d’un chemin, plusieurs PTI peuvent coexister pendant un remplacement, mais une seule doit être active.

Le RFC avertit qu’activer simultanément plusieurs PTI du chemin actif peut livrer des paquets en double aux feuilles. L’avertissement montre pourquoi le seul état « politique active » ne suffit pas. Pendant un make-before-break, le contrôleur construit une nouvelle instance, l’active, puis retire l’ancienne. Les deux portent le même Tree-ID mais des Instance-ID et des états de réplication différents.

Un écran qui agrège tout au niveau de la politique efface ce passage. Après coup, il peut être impossible de savoir si le test visait l’ancienne instance, la nouvelle, ou si les deux ont reçu du trafic pendant une période inattendue. Un service sensible à la duplication peut subir un effet même si la continuité du transport paraît excellente.

La séparation entre transport et service ajoute une seconde ambiguïté. Une PTI est habituellement associée à un service multipoint, mais le RFC autorise plusieurs services lorsqu’un contexte de service les distingue aux extrémités. Une preuve sur l’arbre ne prouve donc pas automatiquement le contexte qui a traité la charge utile.

Le contrôleur exerce un pouvoir projeté

Le RFC 9960 permet qu’un opérateur, un nœud ou une machine fournisse au contrôleur la Racine, les feuilles et les chemins candidats. Le contrôleur calcule la topologie, attribue des Replication-SID et instancie l’état par PCEP, BGP, NETCONF/YANG ou d’autres mécanismes. Des arbres statiques restent possibles.

Ce rôle donne au contrôleur le pouvoir effectif de faire copier des paquets. Il ne lui donne pas nécessairement l’autorité de choisir le public. Le propriétaire du service peut être ailleurs. L’automatisation ne reçoit que sa traduction réseau.

La distinction rejoint le Policy Mirror de Heng Lu. Le code en fonctionnement montre qui peut agir et quelle politique est réellement exécutée. Il ne transforme pas l’accès à une API de provisionnement en mandat institutionnel. Pour juger une diffusion, il faut conserver à la fois l’autorité en amont et l’action exercée en aval.

Les échecs doivent aussi garder leur génération. Le RFC prévoit qu’un segment peut échouer à s’installer, notamment en cas de conflit de SID. Il recommande de borner les tentatives, d’émettre une alerte et, selon le cas, de détruire l’instance partielle. Si une nouvelle tentative réutilise la même étiquette d’audit, l’échec disparaît derrière le succès final. L’identité de la tentative est une preuve, pas du bruit.

Le ping est une observation bornée

Le RFC 9961 étend ping et traceroute aux politiques SR P2MP utilisant MPLS. La requête désigne une PTI précise au sein d’un chemin candidat. Elle transporte la Racine, le Tree-ID et l’Instance-ID. Cette granularité permet de vérifier l’instance réalisée au lieu d’un nom de service indéterminé.

Le texte pose lui-même deux limites essentielles. Le sous-TLV teste une PTI précise ; il ne teste pas le chemin candidat comme abstraction. Le mécanisme ne couvre pas SRv6. Une réponse positive établit donc une observation du plan de données MPLS à un instant et dans le périmètre des répondants choisis.

Elle ne démontre pas que l’application a livré un contenu exploitable, que le destinataire avait encore un droit, que les copies sont restées uniques pendant la bascule, ni que la source de la liste des feuilles était à jour. Elle ne valide pas davantage les filtres protégeant la frontière du domaine SR ou l’autorisation du contrôleur.

Dire ces limites ne diminue pas la valeur d’OAM. Au contraire, une preuve étroite peut être reliée proprement à d’autres preuves. Un voyant vert qui ne nomme ni PTI, ni heure, ni périmètre ne le peut pas.

Construire le reçu d’audience

La première ligne du reçu doit précéder la configuration réseau. Elle identifie le service, la source qui fait autorité pour ses membres, la version de cette source, sa période d’effet et la personne responsable. Vient ensuite la résolution entre identités stables et adresses de feuilles ou de Buds. Une adresse seule ne suffit pas, car elle peut changer de titulaire.

Le reçu peut alors joindre sept ensembles :

  1. le service, son contexte, la source d’adhésion, les exclusions et l’approbateur ;
  2. les identités locales des destinataires, leurs adresses, les ajouts, retraits et échéances ;
  3. <Root, Tree-ID>, le tuple d’origine du chemin candidat, ses contraintes et la raison de sa sélection ;
  4. les anciens et nouveaux Instance-ID, la liste exacte des feuilles et Buds, la génération de configuration et les résultats d’installation ;
  5. le protocole OAM, sa portée MPLS, l’instance ciblée, les répondants demandés, l’heure et les résultats par feuille ;
  6. l’ordre d’activation make-before-break, l’intervalle de coexistence, l’observation des doublons et la preuve du retrait de l’ancienne PTI ;
  7. la comparaison finale avec la population autorisée, l’échéance du reçu et la liste explicite de ce qui n’a pas été prouvé.

Un hachage peut rendre visibles les substitutions entre population, configuration et mesures. Il ne certifie ni la légitimité de la source ni la véracité d’un capteur. La liste des destinataires peut être sensible ; un registre public peut publier des comptes, dates et exceptions sans révéler les clients ou les adresses.

Le terme « reçu d’audience » est proposé ici. Il n’apparaît pas comme obligation dans les RFC. Une norme Internet réutilisable doit laisser à chaque opérateur son droit des contrats, ses rôles et son calendrier, tout en offrant les identifiants techniques nécessaires pour joindre ces décisions.

Fermer l’ancienne audience

La qualité d’une bascule ne se mesure pas seulement à l’activation de la nouvelle PTI. Il faut démontrer que l’ancienne n’achemine plus, que les feuilles supprimées ont disparu des instances de secours et que les états partiellement installés ont été détruits.

Cette exigence est plus forte pour un Bud, qui reçoit et réplique. Une réponse du nœud ne révèle pas à elle seule si ses branches en aval sont celles qui étaient autorisées. L’état de terminaison et l’état de réplication doivent être comparés séparément.

Les considérations de sécurité du RFC 9960 rappellent qu’une frontière SR mal protégée peut permettre l’injection de paquets et qu’une boucle créée par un contrôleur peut provoquer une tempête jusqu’à expiration du TTL ou du Hop Limit. Un ping réussi n’annule aucune de ces conditions. Elles appartiennent au dossier de décision avec leurs propres contrôles.

Limites et sources

Les documents examinés ne prouvent le déploiement chez aucun opérateur nommé, aucune inclusion abusive, aucun doublon réel ni un gain de performance. Ils définissent des mécanismes et des risques. Une exploitation peut choisir MPLS, SRv6, un arbre statique, une autre observation ou aucun déploiement P2MP.

La conclusion reste bornée : la politique identifie le mécanisme, la PTI identifie sa réalisation et le ping décrit une observation. Le droit de distribuer à ces feuilles doit venir d’une autre source et survivre dans une preuve jointe.