Résumé

  • RFC 10018 permet d’annoncer un P-tunnel SR P2MP par <Root, Tree-ID> et d’alimenter son ensemble de feuilles au moyen des routes MVPN ou EVPN A-D. Il décrit ainsi une chaîne de contrôle vérifiable, sans garantir qu’un PTI complet a été installé ni que la charge utile a atteint chaque feuille prévue.
  • La clôture doit comparer, pour le même candidat et le même Instance-ID, les feuilles commandées, découvertes, acceptées par le contrôleur, programmées, visibles dans le forwarding, joignables par OAM et confirmées par la charge utile. Le retrait mérite la même granularité.

La majorité n’est pas une mesure de complétude

Une arborescence P2MP transforme un paquet à la racine en plusieurs copies en chemin. C’est son intérêt économique et opérationnel. C’est aussi la raison pour laquelle une branche défaillante peut disparaître dans les moyennes : le débit total reste élevé, les compteurs de la racine progressent et la plupart des récepteurs se déclarent satisfaits.

Supposons qu’un changement concerne huit PE de sortie. Le contrôleur publie un état actif. Sept sondes reçoivent le flux. La huitième reste muette. Dire que le service est « presque livré » décrit peut-être le volume ; cela ne dit rien du contrat avec cette feuille, de sa région ou de sa fonction. Dans un service de réplication financière, de vidéo ou de signalisation, la feuille manquante peut être celle qui donne tout son sens à l’arbre.

RFC 10018 rend cette question traitable. Le document définit l’usage de P-tunnels P2MP SR-MPLS ou SRv6 pour MVPN et EVPN, ainsi que l’ingress replication sur SR. Il articule les routes BGP Auto-Discovery, le PMSI Tunnel Attribute, la politique SR P2MP, le contrôleur, les segments de réplication et le contexte de service au PE de sortie.

Il faut pourtant résister à une lecture magique du standard. Une annonce conforme prouve ce qu’un locuteur a annoncé dans le format convenu. Elle ne mesure pas ce qui s’est passé dans chaque plan de données. Le standard fournit les noms qui permettent de confronter ces mondes ; il ne les fusionne pas.

Le même arbre possède plusieurs états civils

Dans le PTA, RFC 10018 identifie la politique par le couple <Root, Tree-ID>. Le Tree-ID, entier non signé de 32 bits, est unique dans le contexte de la racine. Il est encodé avant l’adresse IP de la racine. Les registres IANA réservent 0x0C à l’arbre P2MP SR-MPLS et 0x0D à l’arbre P2MP SRv6.

Ce couple est l’état civil de la politique, pas celui de chaque incarnation de l’arbre. RFC 9960 distingue les chemins candidats et les P2MP Tree Instances. Un candidat peut ne posséder aucun PTI si aucun arbre ne satisfait ses contraintes. Pendant un make-before-break, il peut en posséder plusieurs, mais un seul doit être actif. Deux instances actives du candidat actif peuvent remettre des copies en double aux feuilles.

L’Instance-ID, sur 16 bits, distingue ces incarnations. Les segments de réplication d’un PTI sont identifiés avec Root, Tree-ID, Instance-ID et Node-ID. Une enquête doit donc demander : « quel PTI ? », et non seulement : « quelle politique ? ». Sinon, une réponse OAM de l’ancienne instance peut blanchir la nouvelle, et un accusé d’installation retardé peut être rattaché au mauvais changement.

La durée fait également partie de l’identité opérationnelle. Le même Tree-ID ne signifie pas le même état avant l’ajout d’une feuille, pendant la transition, après le retrait et lors d’une éventuelle réutilisation. Un journal qui n’enregistre qu’un instantané final perd la succession des autorités.

L’auto-découverte ne livre pas de paquet

Pour MVPN, l’entrée PE crée un chemin candidat lorsqu’elle émet les routes A-D pertinentes avec un PTA de type SR P2MP. Elle le supprime lorsque la route qui annonce le P-tunnel est retirée. L’import d’une Intra-AS I-PMSI ou d’une Leaf A-D provenant d’un PE de sortie ajoute ce PE à l’ensemble des feuilles ; le retrait de cette route l’en enlève. Certains cas imposent le drapeau Leaf Information Required et la création d’une Leaf A-D par la sortie.

EVPN suit une mécanique analogue avec IMET, S-PMSI et Leaf A-D. Cette symétrie est précieuse : l’appartenance n’est plus une hypothèse enfouie dans une base de contrôleur. Elle devient un événement de protocole avec une origine et un retrait.

Mais l’événement n’a pas d’autorité sur les étapes suivantes. Le module MVPN/EVPN doit transmettre le chemin candidat et l’ensemble des feuilles au module SR P2MP Policy. Celui-ci communique avec un contrôleur par un mécanisme possible tel que PCEP, BGP ou NETCONF. RFC 10018 laisse ces procédures hors de son périmètre.

Une Leaf A-D reçue peut donc coexister avec un contrôleur qui travaille encore sur la version précédente. Un retrait peut être correct dans BGP alors que le PTI continue de contenir la branche. Une feuille peut rejoindre localement comme Leaf ou Bud sans que tous les segments intermédiaires existent. « Présent dans A-D » est une preuve d’appartenance de contrôle, pas une preuve de transport.

Il en résulte une règle simple : conserver la version de l’ensemble de feuilles à chaque passage. L’intention de service, le module d’entrée, le contrôleur et le PTI doivent pouvoir nommer le même ensemble au même moment. Un simple compteur ne suffit jamais ; deux ensembles de huit membres peuvent différer d’une feuille.

Une installation partielle n’est pas un accident non représentable

RFC 9960 prévoit explicitement que l’instanciation d’un segment de réplication puisse échouer. Un conflit de Replication-SID en est un exemple. Le nœud devrait signaler la réussite ou l’échec, de préférence avec une raison. Le contrôleur devrait retenter l’opération dans une limite, puis émettre une alerte si l’échec devient terminal. Il peut démonter le PTI lorsque certains segments manquent ; il est recommandé de le faire si le segment de la racine échoue.

Ces formulations montrent que l’état n’est pas binaire. Un PTI peut être calculé mais non demandé ; demandé mais partiellement accepté ; accepté selon le contrôleur mais absent du FIB d’un nœud ; installé en aval mais non activé à la racine ; actif tout en étant incomplet au regard du contrat de service.

RFC 9960 décrit une stratégie utile : programmer d’abord les feuilles et les nœuds intermédiaires, puis la racine lorsque ces opérations ont réussi. La racine devient ainsi la dernière vanne. Ce séquencement n’est pas une preuve du comportement d’un produit précis. Il fournit en revanche une question de gouvernance : quelle condition exacte autorise le contrôleur à rendre l’instance active ?

Un statut global sans détail par nœud n’est pas contrôlable. L’interface opérationnelle devrait exposer le Node-ID, le Replication-SID, la révision demandée, l’acquittement, la raison d’échec, le nombre de tentatives et l’état terminal. Si le fournisseur ne peut pas expliquer comment ACTIVE est calculé, cette valeur est une convention d’affichage, pas une preuve.

La bonne branche peut remettre la charge au mauvais service

Le Tree-SID identifie le PTI dans le plan de données. La racine encapsule, les nœuds P répliquent au moyen de leurs segments, puis la feuille retire le Tree-SID et remet la charge utile. Ce mécanisme établit le chemin de l’arbre ; le contexte de remise peut demander un autre identifiant.

Lorsqu’un P-tunnel est réservé à une MVPN, le Tree-SID peut suffire à retrouver l’instance. Si plusieurs MVPN partagent l’arbre, un label MPLS attribué en amont ou un SRv6 Multicast Service SID donne le contexte. RFC 10018 ajoute les comportements End.DTMC4, End.DTMC6 et End.DTMC46, auxquels IANA attribue respectivement 76, 77 et 78, ainsi que des contraintes de transposition pour certains encodages SRv6.

Une branche peut donc fonctionner tandis que la remise finale échoue. Un mauvais label peut sélectionner une autre MVPN. Un service SID ou une transposition incohérente peut empêcher la consultation de la bonne table multicast. Une sonde attachée seulement au Tree-SID ne démontre pas que la charge a rejoint le bon locataire.

EVPN ajoute le split horizon pour les Ethernet Segments multihomés. Il évite la duplication de trafic BUM. SR-MPLS place le label ESI dans la pile requise ; SRv6 utilise Arg.FE2 avec End.DT2M. Recevoir une copie ne suffit donc pas : une feuille peut recevoir une copie qu’elle aurait dû filtrer, ou deux copies sous une apparence de disponibilité parfaite.

La mesure terminale doit contenir PTI, feuille, MVPN/EVI, identifiant de service, résultat de filtrage et signature de la charge. « La branche répond » est trop peu précis.

L’ingress replication change de responsable

Dans l’ingress replication, l’entrée PE fabrique une copie pour chaque sortie et l’envoie par un chemin unicast. RFC 10018 précise que le module SR P2MP Policy et le contrôleur ne participent pas à ce mode.

Cette différence empêche d’utiliser le même tableau de bord. Pour l’IR, il faut examiner la liste des sorties, l’identifiant de service reçu de chaque sortie, la politique unicast ou SR-TE choisie et la copie correspondante. Pour un arbre SR P2MP, il faut suivre le PTI, les segments cousus, l’instance active et l’OAM d’arbre.

L’autorité de traitement du trafic diffère aussi. L’IR peut associer un traitement par sortie dans les cas décrits. Une PTI réplique dans l’arbre ; l’entrée impose donc un traitement de traffic engineering commun au P-tunnel, sans différencier chaque feuille.

Un basculement P2MP vers IR est un changement de modèle, pas seulement une nouvelle route. Le journal doit montrer l’arrêt de l’injection dans l’ancien PTI, le début des copies unicast, leur éventuel chevauchement et la suppression finale de l’état P2MP. Faute de quoi, la restauration peut se traduire par une double livraison.

Une sonde doit porter le nom de ce qu’elle teste

RFC 9961 définit le ping et le traceroute pour SR P2MP Policy. Les paquets OAM ciblent un chemin candidat et un PTI précis, sont répliqués selon l’état du PTI et provoquent des réponses des feuilles. Les implémentations devraient permettre de tester séparément chaque candidat et chaque instance, même inactive.

Cette capacité évite une confusion temporelle. Pendant un make-before-break, la réussite de l’ancien PTI ne vaut pas pour le nouveau. Le résultat doit conserver l’Instance-ID, l’heure, l’ensemble attendu et les réponses individuelles.

Pour des segments de réplication non adjacents, deux instruments sont nécessaires : l’OAM P2MP vérifie la structure de réplication, tandis que l’OAM unicast vérifie le chemin qui relie les segments. RFC 9961 ne revendique pas la détection des pannes de ce chemin unicast. Une couche ne doit pas être déclarée saine grâce à l’absence de test dans l’autre.

Enfin, le ping n’est pas la charge utile. Il peut établir qu’un contexte de forwarding a traité une requête. Il ne prouve ni le bon service SID, ni la perte acceptable, ni le filtrage EVPN, ni la réception par l’application. La clôture a besoin d’un canari de charge : séquence connue, marque de contenu attribuable, compteur lié au contexte ou accusé applicatif. Ce canari doit reprendre l’identité complète du PTI.

La clôture se calcule par différences d’ensembles

Une organisation peut conserver huit ensembles de feuilles :

  • E, les sorties exigées par le service ;
  • A, les sorties présentes dans l’état A-D applicable ;
  • C, les feuilles acceptées par le contrôleur pour le candidat courant ;
  • I, les feuilles dont le chemin de segments est entièrement installé pour ce PTI ;
  • F, celles présentes dans le forwarding actuel de l’instance active ;
  • O, celles qui répondent à l’OAM du candidat et de l’Instance-ID exacts ;
  • D, celles qui reçoivent la bonne charge dans la bonne MVPN ou EVI ;
  • W, les anciennes feuilles dont le retrait, la déprogrammation et la quiescence sont prouvés.

Un service strict peut exiger E = A = C = I = F = O = D avant activation. Un mode dégradé peut admettre un sous-ensemble nommé, pour une durée et un impact explicités. Le retrait n’est clos que lorsque l’ancienne feuille a quitté les ensembles actifs et rejoint W.

Les différences orientent immédiatement l’enquête. E − A relève de la commande et de l’auto-découverte. A − C révèle un retard ou un filtre entre service et contrôleur. C − I montre une installation incomplète. I − F conteste la portée d’un acquittement. F − O indique une divergence de forwarding ou de diagnostic. O − D déplace l’analyse vers le contexte de service et l’application.

L’égalité des tailles ne suffit pas. Les membres et les époques doivent être identiques. Huit réponses, dont une ancienne feuille retirée, ne prouvent pas la disponibilité des huit feuilles actuelles.

Les limites de la preuve publique

Les RFC et registres cités établissent des mécanismes, des identifiants et des transitions normatives. Ils n’établissent pas l’usage du mécanisme par un opérateur nommé, le support intégral d’un produit, la fréquence des pannes ni l’existence réelle du cas hypothétique à huit feuilles.

Une valeur IANA prouve une attribution sémantique. Elle ne prouve pas qu’un binaire l’implémente ou qu’un FIB l’a installée. Le statut Standards Track ne rend pas le déploiement obligatoire. L’IETF définit un langage commun ; elle n’active pas le PTI d’un opérateur.

La lecture rejoint la primauté du code en exécution de Lu Heng : une affirmation documentaire doit rester réfutable par l’état observable. Elle rejoint aussi la spécification initiale minimale et la décision future localisée : l’interopérabilité commune peut être ferme sans confisquer la décision locale de déploiement et de risque.

Le plan de données n’est pas infaillible pour autant. Un état réellement installé peut être périmé ou non autorisé. La réalité opérationnelle corrige les slogans ; le contrat et le contexte disent si cette réalité est acceptable.

Sources