Résumé

  • Une interface PLI configurée accepte des Join/Prune sans avoir reçu de Hello de leur émetteur. Elle n’obtient pas pour autant la découverte des voisins, l’élection DR ou Assert.
  • Le choix du routeur qui relaie le Join côté récepteur et celui de la source de trafic amont répondent à deux problèmes différents ; la redondance doit traiter chacun.
  • Les capacités d’attribut, le passage d’une détection de panne au retrait OIF et les rôles TCP PORT sont des dépendances explicites, non des garanties apportées par le nom PIM Light.

Analyse

Un cœur de transit n’a pas nécessairement besoin de devenir le voisin PIM de toutes les bordures qu’il relie. Dans l’architecture BIER, les nœuds intermédiaires n’entretiennent pas l’état multicast de chaque flux ni les arbres traditionnels. Les domaines PIM situés aux extrémités ont pourtant encore des demandes à échanger. Leur imposer un voisinage complet à travers le cœur reviendrait à réintroduire une partie du travail que l’architecture cherche à séparer.

C’est à cette frontière que la RFC 9739, publiée sur la voie des standards en mars 2025, définit PIM Light et la PIM Light Interface, ou PLI. Un Join/Prune peut y créer un état multicast sans Hello préalable. La possibilité est utile ; son périmètre doit rester précis.

Imaginons maintenant que deux routeurs redondants soient ajoutés à une bordure. Les demandes peuvent toujours traverser le cœur. Mais lequel des deux les relaiera, et comment éviter que deux équipements amont livrent le même flux à une bordure aval ? Il s’agit ici d’une question de conception hypothétique, pas d’un incident observé. Elle révèle deux choix que l’interface allégée ne réalise pas.

Deux endroits où décider

Le premier se trouve dans le domaine PIM qui porte les demandes des récepteurs. Dans l’exemple BIER de la RFC 9739, les routeurs de bordure redondants doivent conserver une adjacence PIM ordinaire. L’élection du Designated Router se déroule donc dans le domaine PIM, et seul le DR transmet le Join/Prune reçu vers le tunnel BIER.

Il serait inexact d’en conclure que PLI élit son DR. L’interface ne traite pas les Hello qui rendent cette élection possible. Le mécanisme reste du côté où il peut encore fonctionner. Un cœur sans voisinage PIM complet n’implique pas une bordure privée de ses échanges locaux.

Le deuxième choix concerne le trafic venant de l’amont. Sur un support partagé, plusieurs routeurs PIM peuvent disposer d’un état de transmission valide pour le même paquet. La RFC 7761, section 4.6, explique qu’Assert détecte cette duplication et élit un seul transmetteur. Le gagnant Assert et le DR n’ont pas la même fonction.

PIM Light ne traite pas Assert. La RFC 9739 impose donc aux applications ou aux réseaux utilisant PLI d’empêcher la duplication. Ce n’est pas une promesse selon laquelle l’interface découvrira les doublons et les corrigera après coup.

Son illustration BIER identifie des bordures amont candidates à partir de la topologie, puis en choisit une avec une règle unique, par exemple l’adresse IP la plus basse ou la plus haute. La sélection d’une remplaçante après panne reste hors du détail algorithmique de la RFC. Il faut conserver la différence entre cet exemple, l’obligation de ne pas dupliquer et le comportement d’une réalisation particulière.

Pour une recette proposée, les deux choix doivent pouvoir être éprouvés séparément. L’élection DR peut rester stable pendant que la bordure amont sélectionnée disparaît. Inversement, le fournisseur du flux peut rester disponible pendant que le DR change. La remise en service d’un équipement mérite aussi un essai : choisir un seul candidat ne suffit pas si l’ancien et le nouveau deviennent simultanément efficaces.

L’exception ne s’étend pas à toutes les interfaces

Le comportement ordinaire de PIM-SM est plus restrictif. La section 4.5 de la RFC 7761 recommande de rejeter un Join/Prune venant d’une adresse dont aucun Hello n’a été vu. Une exception de compatibilité existe pour certaines anciennes réalisations point à point, sans vocation à être activée par défaut.

PLI autorise explicitement l’émetteur inconnu, mais conserve de l’état de routage multicast plutôt qu’un état général de voisinage. Elle ne découvre ni les autres routeurs ni leurs capacités. La RFC 9739 exige le rejet d’un Join/Prune sans voisinage connu si PLI n’est pas activée sur l’interface d’arrivée.

Une interface logique peut être activée automatiquement par un mécanisme sous-jacent. Cela ne transforme pas l’exception en autorisation globale. La conception doit permettre d’identifier la relation qui a créé l’interface, son encapsulation et son périmètre. Faire accepter les mêmes octets à la PLI prévue et les faire rejeter ailleurs serait un test pertinent ; ce document ne rapporte pas son exécution en production.

Le périmètre des messages mérite la même discipline. PIM Light prend en charge Register (1), Register Stop (2), Join/Prune (3), Candidate RP Advertisement (8), Packed Null-Register (13.0), Packed Register-Stop (13.1), ainsi que les futurs types ayant une destination IP unicast. Les autres types ne doivent pas être traités. Le registre IANA confirme les codes, pas leur présence dans un produit.

Un exemple qui ne transmet que des Join/Prune n’est donc pas la définition de tout PIM Light. Le protocole couvre PIM-SM, dont PIM-SSM, mais exclut PIM-DM et BIDIR-PIM. Les états (*,G), (S,G) et (S,G,rpt) appartiennent aux procédures sparse mode. Une recette limitée à SSM ne démontre pas l’ensemble des comportements d’arbre partagé.

Des attributs sans annonce de capacité

La RFC 5384 définit l’enveloppe des Join Attributes. Comprendre l’encodage source de type 1 ne signifie pas comprendre chaque attribut. Même dans PIM ordinaire, l’option Hello annonce le format commun, pas toutes ses significations possibles.

Sans cette option, PIM Light ne connaît pas la capacité du voisin. La RFC 9739 recommande de ne pas envoyer de Join avec attribut, sauf lorsque la configuration établit la capacité des voisins ou qu’une autre RFC ou un Internet-Draft l’autorise expressément dans le scénario concerné.

L’exception par configuration doit donc avoir un objet : quels pairs, quel attribut, quelle portée logicielle ? L’exception documentaire doit avoir une référence et un scénario. Une formule commerciale comme « extensions PIM prises en charge » n’établit aucune des deux.

Cette dépendance suit le cycle de vie des équipements. Remplacer un pair peut laisser les Join ordinaires fonctionner tout en invalidant la connaissance qui rendait un attribut sûr. L’absence de Hello est alors le fonctionnement prévu, pas une alarme susceptible de signaler le changement. Il s’agit d’une conséquence déduite de l’architecture, non d’une panne documentée par les sources.

Détecter puis retirer

La RFC 9739 décrit une autre perte : certaines pannes de PLI peuvent rester indétectées, sans Prune envoyé vers la source. Le trafic amont continue alors jusqu’à l’expiration de l’interface de sortie, ou OIF.

Elle permet des mécanismes de détection dépendant de l’implémentation. Dans l’exemple BFD, si la session vers la PLI distante tombe et que le routeur amont possède cette PLI dans la liste OIF d’un (S,G), PIM doit l’en retirer. Dans l’exemple d’interface BIER automatiquement créée, la perte de joignabilité de la bordure aval peut permettre à la bordure amont d’envoyer un Prune (S,G) vers la source.

Le caractère conditionnel est essentiel. Il n’existe ici ni couverture BFD universelle ni délai de retrait commun à tous les produits. La chaîne à préciser relie l’objet surveillé, le résultat de détection et l’action PIM. Une alarme apparue sans retrait de la bonne OIF ne réalise pas cette action.

Une expérience de laboratoire proposée devrait distinguer la panne du pair sélectionné, celle du chemin surveillé et la perte de notification entre détecteur et PIM. Les observations porteraient sur l’interface effectivement retirée, l’état concerné et le Prune émis. Les RFC ne fournissent pas des résultats mesurés pour ces expériences.

PORT ne reconstitue pas les décisions absentes

La RFC expérimentale 6559 définit PORT, le transport fiable des Join/Prune sur TCP ou SCTP, avec le port de destination 8471. Dans PORT ordinaire, des Hello annoncent la capacité et un Connection ID : une adresse IPv4 ou IPv6 utilisée pour établir la connexion.

Les règles TCP ordinaires utilisent ces adresses pour répartir les ouvertures active et passive, avec des exceptions pour les connexions à la demande. SCTP sait gérer la collision d’appels. Une PLI n’ayant pas de Hello pour transmettre l’information, la RFC 9739 permet de configurer le Connection ID. Pour TCP PORT, les rôles actif et passif doivent être explicitement et correctement configurés aux deux extrémités.

Cette adresse ne constitue ni un jeton de session de type QUIC, ni une élection DR, ni une preuve d’identité. Il faut aussi conserver l’entretien de la connexion. La RFC 6559 explique qu’un TCP silencieux peut ne pas révéler rapidement la disparition d’un pair ; elle fournit des mécanismes Keep-Alive et d’expiration sans imposer un Holdtime par défaut unique.

Une connexion rétablie exige le renvoi de l’état Join/Prune complet pertinent. Sa perte déclenche les minuteries d’expiration de l’état OIF associé, sauf rafraîchissement ultérieur ; elle n’autorise pas un repli automatique vers les Join/Prune natifs en datagrammes. La fiabilité du transport, la resynchronisation et le retrait d’une PLI défaillante sont donc des comportements à relier, pas à confondre.

Ce que les sources permettent d’affirmer

La politique de routes constitue une seconde défense : la RFC 9739 recommande de ne traiter que les (S,G) attendus et exige de rejeter les autres. Cela borne l’admission d’état sans authentifier l’émetteur. Elle renvoie aux mécanismes IPsec de la RFC 5796, avec ESP et éventuellement AH. La RFC 4607 avertit également que choisir une source SSM ne fournit pas une authentification forte.

La RFC 8279 justifie la séparation BIER au sein du cœur, non l’effacement de l’état PIM aux bordures. Le document distinct BIER-PIM signalling apparaît, dans la capture officielle du 13 septembre 2026, comme le draft expiré de révision 13 daté du 3 mars 2025. L’exemple cité par la RFC 9739 ne doit pas devenir une autre norme achevée ou une preuve d’adoption actuelle.

Ces sources ne mesurent ni incidents d’exploitation, ni économies, ni performances de bascule. Elles établissent une répartition concrète : alléger le voisinage à une frontière est possible si l’architecture garde les décisions qu’elle ne confie plus à l’interface.

Sources

L’image est une métaphore éditoriale créée par IA, pas une topologie vérifiée ni un relevé de déploiement.