Résumé

  • Le projet LISP multicast en cours indique qu’après la perte d’un ITR racine, les ETR récepteurs doivent reconstruire l’état vers un nouvel encapsulateur et lui renvoyer le flux (S-EID,G) attendu.
  • L’anycast peut conserver le RLOC et ramener la transition de l’underlay à un changement RPF. L’ETR peut toutefois ignorer que l’instance physique a changé ; le successeur attend alors le prochain Join/Prune périodique pour apprendre l’état propre au récepteur.
  • Daniel Kade propose un reçu de succession de racine et une dette explicite de rejeu des joins. Ce sont des instruments d’exploitation et de gouvernance, pas des extensions de LISP ou de PIM.

Une adresse revenue n’est pas un arbre revenu

Prenons un programme vidéo distribué depuis un site source vers plusieurs réseaux. L’Ingress Tunnel Router du site tombe. Le routage attire le RLOC anycast vers un second ITR. Les sondes adressées au RLOC repassent au vert et, dans un underlay multicast, le chemin inverse se réoriente. L’équipe réseau peut légitimement constater une convergence rapide.

Elle n’a pas encore démontré la reprise du service. L’ancien ITR savait quels ETR distants avaient rejoint quels couples source-groupe. La nouvelle machine peut être parfaitement joignable sans posséder cet état. Le nom de la racine demeure ; sa mémoire opérationnelle, elle, appartenait à l’instance disparue. Tant que les sites récepteurs ne rejouent pas leur intention, le successeur peut ignorer ce qu’il doit encapsuler et vers qui.

Il ne s’agit pas de reprocher à l’anycast une promesse qu’il n’a jamais faite. L’anycast permet à plusieurs emplacements d’annoncer une adresse et laisse le routage choisir une instance. Il n’assure pas la réplication de l’état d’un protocole. La faute de gouvernance consiste à transformer une preuve de joignabilité de l’adresse en attestation de continuité pour tous les services avec état qui se trouvent derrière elle.

draft-ietf-lisp-rfc6831bis-07 est un projet actif en évaluation par l’IESG. Il vise le statut Proposed Standard et remplacerait le RFC 6831 expérimental s’il était approuvé. La révision 07 date du 11 septembre 2026. La comparaison avec la révision 06 montre surtout des formulations normatives, des références IGMP et MLD actualisées et des retouches éditoriales. Le mécanisme étudié ici appartient à l’architecture courante du document ; ce n’est pas une nouveauté artificiellement attribuée au numéro 07.

Deux espaces de noms, une chaîne de garde

LISP sépare l’Endpoint Identifier, utilisé pour nommer la source dans les sites, du Routing Locator employé par l’underlay. Le découplage facilite la mobilité du point d’attachement, mais le multicast impose de maintenir des états coordonnés dans les deux espaces.

Un hôte récepteur rejoint (S-EID,G) avec IGMPv3 ou MLDv2. À la frontière, son ETR recherche le S-EID et choisit un RLOC d’ITR source selon les priorités et les poids de la cartographie. Sur un underlay multicast, l’ETR émet deux signaux. Un Join/Prune PIM encapsulé en unicast porte (S-EID,G) jusqu’à l’ITR sélectionné. Un autre Join/Prune construit l’état (S-RLOC,G) dans l’underlay. Le premier exprime le flux interne demandé ; le second forme un arbre dont la racine est un locator.

Avec un underlay unicast, l’ITR tient explicitement une liste de RLOC d’ETR récepteurs et effectue la réplication en tête : une copie externe par destination. Dans les deux cas, l’ETR de réception retire l’en-tête LISP et consulte son état multicast interne (S-EID,G) avant de remettre le paquet à ses interfaces locales.

Ces preuves ne sont pas fongibles. Un Map-Reply révèle des locators sans prouver l’installation du flux dans une instance physique. Un RPF correct montre un chemin sous-jacent sans prouver que la racine connaît le S-EID. Un join local conservé ne garantit pas que l’encapsulateur distant s’en souvient. Un paquet peut même atteindre un ETR par un arbre (RLOC,G) partagé et être écarté faute d’état interne correspondant.

L’objet exploitable est ainsi une chaîne : intention du récepteur, état de frontière ETR, racine physique sélectionnée, état EID dans l’ITR, réplication dans l’underlay ou en tête, acceptation par l’ETR et observation finale. Chaque maillon a son responsable et son horloge.

Le changement de racine crée une obligation

La section 6 du projet distingue l’échec d’un ITR d’un simple ajustement RPF. En unicast, la joignabilité locale peut permettre de changer de locator paquet par paquet. En multicast LISP, l’ITR sélectionné est la racine d’encapsulation de l’arbre. Lorsqu’il devient inaccessible, les ETR déjà joints doivent créer un nouvel état (S-RLOC,G) vers le successeur et lui adresser un Join/Prune encapsulé indiquant le (S-EID,G) voulu.

Cette obligation a une population mesurable : les ETR affectés. Elle a aussi un contenu : les états source-groupe qu’ils attendent sur la nouvelle racine. Les sites ne détectent pas tous l’événement au même instant, ne choisissent pas forcément le même ITR et ne rejouent pas simultanément. Un horodatage global « basculement terminé » ne décrit pas honnêtement cette dispersion.

L’anycast réduit parfois la perturbation visible. Plusieurs ITR partagent le même RLOC ; le routage déplace l’adresse et l’underlay ne voit qu’un changement d’interface RPF. Mais l’ETR distant n’observe aucune modification d’adresse. Il peut donc ne pas déclencher immédiatement le Join/Prune unicast qui réintroduit (S-EID,G). Le projet précise que le nouvel ITR anycast peut n’apprendre cet état qu’au prochain envoi périodique de l’ETR.

Le document ne donne pas un délai universel, et cet article n’en invente pas. Les timers PIM, la mise en œuvre, les pertes, la convergence et le type d’underlay modifient l’intervalle. Toutes les transitions ne produiront pas la même perte, ni même nécessairement une perte visible. La conclusion robuste est plus étroite : joindre l’adresse et retrouver l’état sont deux événements différents.

Comptabiliser la dette de rejeu

J’appelle dette de rejeu des joins l’ensemble des intentions réceptrices qui n’ont pas encore été démontrées sur le nouvel ITR. Au moment de la succession, chaque ETR dont l’état (S-EID,G) reste sans preuve devient une entrée ouverte. Le mot dette ne désigne ni une faute morale ni un compteur de paquets ; il empêche une transition distribuée de disparaître derrière un seul voyant vert.

Une entrée minimale lie l’ETR, le S-EID, le groupe, l’ancien ITR, le successeur attendu, la génération du dernier join, l’heure du dernier rafraîchissement, le mode d’underlay et la preuve de clôture. Si l’équipement expose un accusé d’installation, il peut être utilisé. Sinon, une inspection bornée de l’état racine doit être reliée à une observation à l’ETR ou à un récepteur témoin maîtrisé.

Un ping réussi vers le RLOC anycast, une route présente dans la RIB, une entrée de cache de mapping, une adjacency PIM ou un processus sain ne soldent pas cette dette. Aucun ne prouve que l’intention de ce récepteur a franchi la frontière vers cette instance. La reprise d’un site n’acquitte pas non plus les autres.

La dette peut se fermer autrement que par une reprise. Le récepteur a pu quitter le groupe, la source s’arrêter ou la politique déplacer le flux. La clôture doit alors porter un motif et une autorité : état installé et observé, retrait explicite, expiration selon une règle déclarée ou dégradation acceptée par un responsable nommé. Une disparition silencieuse n’est pas une preuve.

Le reçu de succession de racine

Le reçu de succession de racine rassemble ces pièces. C’est une proposition de gouvernance de Daniel Kade, non un nouveau champ sur le réseau. Son rôle est d’empêcher qu’une équipe ferme l’incident avec la seule couche qu’elle contrôle.

Le reçu identifie d’abord les anciennes et nouvelles instances physiques, leurs RLOC propres ou communs, la source de détection, l’heure, le niveau de confiance, la version de cartographie et le détenteur de l’autorité opérationnelle. Inscrire uniquement l’adresse partagée manquerait précisément la succession cachée.

Il suit ensuite l’état de contrôle par portée affectée : dernier (S-EID,G) connu sur l’ancienne racine, nouvelle sélection, convergence RPF, génération du join à l’ETR, rejeu encapsulé et installation observable chez le successeur. Le point de collecte et l’origine de l’horloge doivent accompagner les événements ; des temps non comparables ne doivent pas être ordonnés comme une causalité certaine.

Enfin viennent les conséquences : premier paquet accepté par le nouvel ITR, première réception sur chaque ETR échantillonné, continuité de séquence ou d’application si elle existe, fenêtre de perte ou de duplication, trafic indésirable rejeté par la recherche interne, et âge de la dette restante. Une preuve de routeur ne doit pas être libellée « application saine ».

Le même reçu désigne l’autorité de retour arrière. Selon l’implémentation, il peut s’agir de restaurer un locator unicast précis, drainer le successeur, provoquer un rafraîchissement contrôlé, déplacer le flux ou accepter temporairement une réplication en tête. Il n’existe pas de commande universelle à décréter ici ; il faut en revanche nommer l’action, sa portée, son décideur et son critère de succès.

La réplication déplace aussi la preuve

Le projet situe la réplication à plusieurs endroits possibles : dans le site, dans un routeur de transit de l’underlay, sur des ETR ou sur des ITR. L’underlay multicast porte davantage d’état intermédiaire ; l’underlay unicast transfère le coût vers les copies et la bande passante au site source. Les priorités d’un Map-Reply peuvent aussi orienter différents récepteurs vers différents ITR.

L’observabilité doit suivre ce déplacement. Une liste d’ETR à l’ITR est un plan de réplication, non un reçu de livraison. Un arbre (S-RLOC,G) sain peut agréger plusieurs sources internes. Le texte prévoit qu’un site reçoive un flux interne qu’il n’a pas demandé parce qu’il partage le même arbre, puis le rejette lors de la recherche (S-EID,G). La décision locale est correcte, mais la capacité commune a déjà été consommée.

La distinction vaut aussi pour la sécurité. Le projet évoque un site malveillant capable de provoquer l’arrivée de trafic non demandé chez des sites légitimes partageant l’arbre. « Le paquet a atteint l’ETR » peut alors signifier réussite, gaspillage ou attaque. Seuls l’état interne et l’ensemble attendu des récepteurs donnent le sens.

Ne pas combler l’angle mort par une affirmation

Le projet exclut de son périmètre le détail de la joignabilité des locators, certains comportements mPITR et la conception de mtrace pour LISP multicast. Il indique que cette dernière reste à définir à partir de Mtrace Version 2. Un diagnostic générique de chemin ne constitue donc pas une vue complète à travers les espaces EID et RLOC.

Chaque mesure doit annoncer sa couche. Un test d’underlay décrit le chemin RLOC ; l’ITR révèle l’installation (S-EID,G) ; l’ETR montre la décapsulation et la recherche interne ; le récepteur montre l’arrivée utile. Leur corrélation peut justifier une conclusion de service. Leur substitution ne le peut pas.

Le projet IETF spécifie un mécanisme et ses frontières, pas un produit universel d’observabilité. La discipline incombe alors aux opérateurs : « le basculement anycast a réussi » doit rester une conclusion sur l’adresse. La reprise multicast exige en plus la succession d’état et l’observation des récepteurs.

Sources

  1. Projet LISP multicast en cours
  2. Historique du projet
  3. Enregistrement API Datatracker
  4. Révision 07 en HTML
  5. Révision 07 en texte
  6. Différence entre les révisions 06 et 07
  7. Groupe de travail LISP
  8. RFC 6831
  9. RFC 9300 : plan de données LISP
  10. RFC 9301 : plan de contrôle LISP
  11. RFC 8059 : attributs PIM Join pour LISP
  12. RFC 7761 : PIM
  13. RFC 8487 : Mtrace Version 2
  14. RFC 9776 : IGMPv3
  15. RFC 9777 : MLDv2
  16. RFC 7799 : terminologie de la mesure
  17. Source XML de la révision 07