Résumé

  • RFC 3446 donna la même adresse Anycast à plusieurs RP PIM-SM actifs afin que sources et récepteurs rejoignent l’instance topologiquement la plus proche.
  • La coordination exigeait l’inverse : appairages MSDP, router IDs et origine/RPF des Source-Active devaient employer des adresses unicast uniques; une route proche ne prouvait ni synchronisation ni livraison.

Une correspondance active rendait la distance coûteuse

Dans RFC 2362, plusieurs RP pouvaient être configurés pour un groupe, mais une seule correspondance groupe-RP était active. Ce centre unique concentrait la décapsulation des Register, ralentissait le basculement et attirait parfois les premiers paquets vers une région lointaine. RFC 3446 donna l’exemple de sources et récepteurs européens passant par un RP américain puis revenant sur des liaisons coûteuses.

Découper 224.0.0.0/4 entre plusieurs RP paraissait équilibrer la charge. L’opérateur devait pourtant connaître à l’avance la distribution du trafic et reconfigurer quand elle changeait. Une partition égale des nombres n’était pas une partition égale du travail.

Publié en janvier 2003, RFC 3446 est Informational. Son texte, sa notice, le Datatracker, l’historique, les références, les citations et les errata prouvent le mécanisme documenté, pas la performance d’un réseau donné.

L’entrée commune choisissait la proximité

Chaque RP recevait la même adresse Anycast, souvent sur une loopback. Les correspondances groupe-RP désignaient cette adresse; chaque instance annonçait le /32 dans l’IGP. Le routage unicast conduisait alors le Register ou le Join vers le chemin annoncé comme le plus proche.

L’économie était réelle : aucun répartiteur nouveau ne décidait globalement. Mais tous les RP devaient partager exactement les mêmes correspondances, et les autres routeurs devaient les apprendre par configuration, Auto-RP ou le bootstrap PIMv2 ensuite défini dans RFC 5059. L’adresse commune ne créait pas cette cohérence.

Le réseau arrière devait nommer chaque réplique

Les RP échangeaient la connaissance des sources par MSDP, ensuite spécifié dans RFC 3618. MBGP restait facultatif, MSDP était requis dans ce dispositif. Ses sessions utilisaient des extrémités unicast uniques.

L’adresse Anycast ne devait pas devenir router ID : des voisinages pouvaient ne pas s’établir. Elle ne devait surtout pas être l’adresse RP d’un message Source-Active, car le contrôle peer-RPF échouerait. L’identité publique répondait à « quelle instance proche ? »; l’identité unique répondait à « quel pair précis a produit cet état ? ». La première cachait volontairement la réplique, la seconde devait la révéler.

MSDP imposait aussi un état (S,G) sur le chemin récepteur-source, absent si les récepteurs demeuraient sur un arbre partagé. Et l’instabilité unicast pouvait changer le RP réellement utilisé sous un nom inchangé. Anycast distribuait un choix; il ne synchronisait ni ne stabilisait magiquement les instances.

Les RFC 4601 et 7761 ont révisé PIM-SM; RFC 4610 a proposé Anycast-RP avec PIM, et RFC 4786 a généralisé l’exploitation Anycast. Ils donnent un contexte, non une causalité automatique. Les registres IANA d’adresses multicast et de paramètres PIM prouvent des symboles, pas un paquet livré.

Plusieurs reçus, pas une disponibilité unique

Les couches de réalité de Heng Lu séparent adresse partagée, route IGP, instance sélectionnée, connaissance MSDP, état PIM, paquet observé et résultat. La primauté du code en fonctionnement donne du poids aux coûts observés des RP lointains et des partitions statiques, sans faire du routage une preuve de service. La spécification initiale minimale éclaire la retenue : partager seulement l’entrée nécessaire, préserver les identités de coordination et laisser la topologie aux opérateurs. C’est une lecture éditoriale.

La leçon est double : les clients ont besoin d’un nom stable qui masque la réplique; les répliques ont besoin de noms stables qui se distinguent. Utiliser un seul nom partout détruit la provenance dont leur coordination dépend.

Sources