Résumé

  • draft-ietf-pim-multicast-over-srv6-01 propose de réutiliser le multicast IPv6 natif dans un réseau SRv6. PIM ou un contrôleur installe des états (S,G) et des listes d’interfaces, pas un chemin multicast ordonné par SID.
  • Flex-Algo peut modifier la route unicast dont PIM déduit l’interface RPF. RFC 9502 impose cependant une participation IP distincte de la participation SR: le même numéro d’algorithme ne constitue pas une preuve commune.
  • L’acceptation doit relier annonce de source, définition de l’algorithme, choix RPF, propriétaire de l’état, programmation des branches, correspondance d’overlay et réception réelle.

Le voyant commun cache des horloges différentes

Sur un écran d’exploitation, tout peut paraître cohérent: locators SRv6 disponibles, source vidéo annoncée sous l’algorithme 128, sessions PIM établies, tunnel MVPN présent. Pourtant, ces voyants ne changent pas au même instant et ne décrivent pas le même objet. Après une variation de métrique, la route unicast peut déjà pointer vers une nouvelle interface tandis que l’ancien état multicast attend encore un prune ou un join. Le paquet qui arrive du côté précédent échoue alors au contrôle RPF dans un réseau dont le tableau SRv6 reste parfaitement vert.

Cette séparation vient des textes eux-mêmes. L’architecture Segment Routing définit un routage à la source pour l’unicast et laisse l’application du concept au multicast hors de son périmètre. La programmation SRv6 décrit des comportements appliqués aux paquets munis d’instructions SR. Le projet PIM en révision 01, dans ses formes HTML et XML, choisit explicitement une autre voie: la distribution multicast est orthogonale à SR et réutilise le multicast IPv6 natif.

Un état natif décrit une source et un groupe, une interface d’arrivée conforme au RPF et des interfaces de sortie. Il ne contient pas une liste de segments ordonnés représentant chaque bifurcation. Dire «multicast sur un réseau SRv6» peut être exact. Dire que l’arbre est segment-routé ou que le locator en prouve les branches ajoute une propriété que le projet ne donne pas.

L’algorithme déplace l’amont, sans devenir l’arbre

PIM-SM pose une question unicast pour construire un chemin multicast: par quelle interface ce routeur rejoindrait-il la source? La réponse devient le côté amont; l’intérêt des récepteurs et l’état PIM définissent le côté aval. Lorsque le préfixe source est annoncé pour Flex-Algo 128, le projet permet à cette route IP contrainte d’orienter le RPF.

Mais 128 n’est qu’un identifiant. RFC 9350 associe à l’algorithme un type de calcul, une métrique et des contraintes, à partager dans le bon périmètre. Un nœud qui ne comprend pas la définition peut cesser de participer et retirer son état. Plus important encore, RFC 9502 fait de l’IP Flex-Algo un plan de données indépendant: la participation IPv4/IPv6 doit être signalée séparément de la participation SR-MPLS ou SRv6.

Un inventaire qui affiche seulement «FA128 supporté» mélange donc au moins trois faits: compréhension de la définition, participation au plan IP et participation au plan SR. Pour le multicast proposé ici, c’est le deuxième fait qui fournit la route RPF. Le troisième peut être vrai, faux ou sans effet sur l’état (S,G). Flex-Algo change la règle de mesure vers la source; PIM conserve le modèle de réplication natif.

PIM et le contrôleur ont besoin d’une frontière de propriété

Le projet permet aussi à un contrôleur central de calculer et d’installer des entrées multicast IPv6 natives. Il ne transforme pas pour autant la table en SRv6. Le routeur doit toujours accepter le bon côté entrant et répliquer vers le bon ensemble d’interfaces. Un accusé de réception d’API prouve au mieux qu’une intention a été acceptée; il ne prouve ni l’application dans le matériel de chaque nœud, ni la circulation d’un paquet, ni la réception au dernier kilomètre.

Les arbres créés par PIM et ceux créés par le contrôleur peuvent coexister à condition d’utiliser des sources et groupes distincts. C’est une condition d’autorité, pas un détail de configuration. Si les deux mécanismes croient posséder le même (S,G), l’un peut vieillir, remplacer ou retirer l’état de l’autre. Le texte renvoie la procédure northbound détaillée à un document complémentaire: autorisation, transaction multi-nœuds et retour arrière ne doivent donc pas être inventés à partir du mot «centralisé».

L’overlay allonge la chaîne de preuve

Dans un service VPN, la branche visible par le client n’est pas directement la branche du fournisseur. L’architecture MVPN et les procédures BGP MVPN séparent l’état multicast client du tunnel fournisseur. RFC 6515 couvre les adresses d’infrastructure IPv4 ou IPv6, RFC 7716 le Global Table Multicast, et RFC 8950 un next hop IPv6 pour une NLRI IPv4.

Dans l’exemple du projet, PIM-SSM établit un arbre fournisseur IPv6 natif, MP-BGP signale le PMSI et les routes multicast client, puis le paquet client voyage dans IP-in-IPv6. La valeur 4 du champ Next Header indique un paquet interne IPv4; 41 indique IPv6. Elle n’identifie ni le VPN autorisé, ni la liste des récepteurs, ni la réussite de la réplication. Le projet précise qu’aucune procédure propre à SRv6 n’est requise. Il faut donc contrôler la liaison entre flux client, PMSI, arbre fournisseur, décapsulation et récepteur; l’architecture de l’underlay ne raccourcit pas ce parcours.

Une nouvelle révision n’est pas une nouvelle preuve

Les instantanés du Datatracker API, de la page du document et de son historique montrent un Internet-Draft actif du groupe PIM. Son en-tête vise le statut Informational, sans AD responsable, shepherd ni téléchat affiché. Ce n’est ni une RFC, ni un recensement de déploiements, ni un résultat d’interopérabilité.

La comparaison figée entre la révision 00 et la révision 01 ne révèle que des changements de date, d’expiration, de numéro et d’en-têtes de page. Aucun mécanisme n’a changé. La phrase de sécurité indiquant l’absence de nouveau problème au-delà des références borne le texte; elle ne garantit ni l’authenticité d’une écriture de contrôleur, ni une définition FA cohérente, ni une bonne correspondance PMSI.

Sources et limites

Le corpus figé comprend la révision 01 texte, HTML et XML, la révision 00, l’API, le statut et l’historique. Le contexte normatif vient de RFC 7761, RFC 6513, RFC 6514, RFC 6515, RFC 7716, RFC 8402, RFC 8950, RFC 9350, RFC 9502 et RFC 8986. Aucune source ne fournit de déploiement nommé, de matrice fournisseur, de temps de convergence, de taux de perte ou de SLA applicatif.