Résumé

  • Le projet PIM daté du 6 septembre transporte topologie, algorithme et plan de données dans un même triplet TAD afin de construire un arbre multicast sur un chemin contraint. La révision 01 actualise les dates et références, sans modifier les règles de la révision 00.
  • Le TAD doit être commun à tout l'arbre et rester dans son domaine IGP. Des Join incompatibles peuvent arrêter la procédure PIM, suspendre l'émission au premier saut, voire produire une boucle.
  • Le repli de compatibilité est une perte de sens : lorsqu'un voisin ne comprend pas le nouveau TLV GSI, sa conversion vers l'ancien GSH supprime les sous-TLV, donc aussi le TAD.

Deux chemins relient une source vidéo à ses abonnés. Le plus court manque de capacité ; l'autre respecte une contrainte de bande passante. L'idée de Flex-Algorithm est de calculer le second. Le problème de PIM est ensuite de faire construire exactement le même arbre par des routeurs qui prennent leurs décisions de proche en proche.

Le document Multi-Topology in PIM propose cette articulation. Sa révision 01, datée du 6 septembre, est un document du groupe PIM visant la Standards Track, mais son état reste I-D Exists. Ce n'est ni un RFC ni une preuve d'exploitation. La comparaison entre le texte 01 et le texte 00 ne révèle que des dates, une échéance et des versions de références mises à jour.

Le triplet ne vote pas routeur par routeur

RFC 7761 décrit la mécanique : les messages Join remontent vers la source ou le RP, créent l'état de l'arbre à chaque saut, puis les paquets suivent le trajet inverse. Le projet ajoute un TAD — Topology, Algorithm, Dataplane — à l'annonce de source et au Join/Prune.

La topologie choisit une vue IGP. L'algorithme peut être celui, sous contraintes, de RFC 9350. Le plan de données distingue notamment Segment Routing, l'IP Flex de RFC 9502 ou un soft dataplane encore proposé. Ensemble, ces valeurs désignent la table qui doit livrer le voisin amont.

Le projet exige donc que tous les routeurs d'un même arbre participent au même TAD. Le FHR annonce source, groupe et sous-TLV TAD par PFM. Le LHR reprend cette information, ou sa politique locale, pour composer l'attribut du Join. Chaque intermédiaire consulte ensuite sa route propre à ce TAD.

Un décodage correct ne prouve pas ce parcours. Il faut encore démontrer que les trois objets existent partout, que la route amont est atteignable, que l'état TIB est programmé en MFIB et que les récepteurs voient les paquets sans perte ni duplication.

Une frontière IGP est aussi une frontière de sens

Le texte interdit de transmettre un TAD local hors du domaine IGP. Les MT-ID sont propres au protocole. Les mécanismes OSPF de RFC 4915 et IS-IS de RFC 5120 ne garantissent pas qu'un même entier représente la même topologie dans le domaine voisin.

Le format ne transporte donc pas son propre dictionnaire. Sa portée vient d'une configuration partagée. Une valeur syntaxiquement valide perd son autorité dès qu'elle traverse vers un espace où son sens n'est plus commun.

Même à l'intérieur, plusieurs arbitrages subsistent. Deux FHR peuvent annoncer des TAD différents pour le même couple source-groupe ; le LHR est invité à départager par l'adresse de l'originator, la plus élevée étant préférée par défaut. Si configuration et annonce du LHR divergent, celui-ci ne doit pas envoyer de Join avec TAD. Si un RPF Vector accompagne le TAD, la politique locale choisit lequel ignorer. Avec plusieurs attributs TAD, le premier est recommandé.

Ces règles sont déterministes séparément. Elles ne prouvent pas que deux équipements ont choisi la même règle locale.

Un arrêt sûr exige une preuve exploitable

Quand les Join reçus pour un même état ne portent pas tous le même TAD, ou quand la table correspondante n'offre aucun amont, le routeur doit arrêter la procédure PIM et prévenir l'administrateur. Le FHR ne devrait pas transmettre tant que les Join ne concordent pas.

Ce comportement évite de fabriquer silencieusement un arbre incohérent. Il peut néanmoins priver des branches saines de trafic. Une alerte « PIM arrêté » ne suffit pas : elle doit conserver les triplets concurrents, leurs voisins, la capacité GSI, la règle appliquée et le dernier état de transfert.

La section sécurité reconnaît qu'une sélection différente de topologie ou d'algorithme selon la politique locale peut créer une boucle ou empêcher le transfert. Un faux routeur peut aussi annoncer un mauvais TAD. Le nouveau champ est donc une entrée qui porte du pouvoir ; il faut en tracer l'origine et la décision, pas seulement sa valeur finale.

La compatibilité enlève l'instruction de chemin

L'annonce TAD dépend du GSI défini par le projet PIM Flooding Mechanism and Source Discovery Enhancements. Ce document est Experimental et se trouve dans la file du RFC Editor. Les voisins annoncent leur capacité par interface dans les Hello PIM.

Si tous comprennent GSI, le TLV riche est relayé sans modification. S'il existe un voisin ancien, le routeur convertit GSI vers le GSH de RFC 8364. Il garde source, groupe et durée de vie, mais doit ignorer les sous-TLV. Le TAD disparaît avec eux.

Ce n'est pas une compatibilité transparente : l'existence de la source traverse, son intention de chemin non. Une validation limitée aux deux extrémités ne voit pas cette coupure. La matrice de capacité doit couvrir chaque interface du trajet de diffusion et de l'arbre.

Selon les couches de réalité de Heng Lu, le texte du projet, la configuration, l'annonce reçue, le TIB, le MFIB et le résultat paquet sont des faits distincts. La primauté du code en exécution refuse de remplacer le dernier par un drapeau « supported ».