Résumé

  • draft-ietf-bier-source-protection-11 décrit un cas où la liaison de contrôle entre BFIR de secours et BFIR sélectionné tombe, mais où le flux du BFIR sélectionné atteint encore tout ou partie des BFER. La relève devient inutile et crée des paquets en double.
  • Un Ping lancé en sens inverse peut lui aussi mentir sur le chemin aller : sans co-routage, il peut échouer alors que le multicast fonctionne, ou réussir alors que le chemin de distribution est rompu.
  • Le chemin mesuré, le verdict du détecteur, le mode de veille, l’acteur autorisé à commuter, les doublons ou pertes, la réception et le résultat applicatif exigent des preuves distinctes. La révision 11 reste un Internet-Draft informatif.

Le signal semblait sans ambiguïté : BFIR2 ne voyait plus BFIR1. Le délai BFD avait expiré. Dans la console d’exploitation, le primaire venait donc de « tomber ». BFIR2 a pris sa place et a commencé à émettre.

Pourtant BFIR1 n’avait cessé d’alimenter aucun des trois récepteurs. La seule rupture se trouvait sur le chemin étroit reliant les deux routeurs d’entrée. Le réseau s’est retrouvé avec deux sources pour le même flux, non parce que la protection avait détecté la panne du service, mais parce qu’elle avait confondu son angle mort avec l’état du service.

C’est la frontière la plus féconde de la révision 11 du projet sur le secours d’entrée BIER. Le texte ne présente pas BFD ou Ping comme des oracles. Il reconnaît que le trajet observé peut être différent de celui que l’automate modifie.

Une topologie, plusieurs réalités dirigées

RFC 8279 fait entrer le paquet multicast par un BFIR et le fait sortir par plusieurs BFER, avec un BitString qui remplace l’état multicast par flux dans le cœur. Le choix de l’Upstream Multicast Hop n’en disparaît pas pour autant. Un protocole d’overlay — MVPN, MLD ou PIM selon le cas — fournit l’information de flux; le transport BIER achemine les paquets.

Le projet nomme S-BFIR l’entrée choisie et B-BFIR son secours. Cette relation peut varier selon le flux et selon le groupe de BFER. Deux récepteurs ne sont pas obligés de considérer le même routeur comme primaire. Parler de « la » panne globale efface donc déjà une partie de l’état.

Trois chemins doivent au minimum rester identifiables :

  1. le chemin B-BFIR vers S-BFIR qui sert à surveiller le primaire;
  2. chaque chemin aller S-BFIR vers BFER qui porte effectivement le flux;
  3. le chemin retour BFER vers S-BFIR emprunté par une requête Ping.

Une rupture du premier prouve que le secours ne reçoit plus le signal attendu sur cette relation. Elle ne prouve ni la mort du nœud, ni la rupture du deuxième chemin. Le document montre précisément qu’en veille chaude BFIR2 peut interpréter la perte de BFIR1 comme une panne, prendre le rôle de S-BFIR, puis dupliquer des paquets alors que BFIR1 continue de servir les BFER.

L’erreur opposée existe aussi. La liaison entre les deux entrées peut rester saine tandis qu’un chemin BFIR1–BFER est coupé. Un détecteur bien vert peut donc coexister avec un service réellement dégradé.

Le mot Down a besoin de son sujet

RFC 5880 décrit BFD sur un chemin de transfert donné. RFC 8562 étend la méthode aux réseaux multipoint. Le projet BIER BFD ajoute le bootstrap et les notifications de queues actives. La vitesse de ces mécanismes n’élargit pas leur portée probatoire.

État enregistré Conclusion soutenable Conclusion abusive
Session B-BFIR/S-BFIR Down La session surveillée a franchi son seuil Tous les chemins vers les BFER sont rompus
Pas de réponse au Ping retour Cette sonde retour n’a pas abouti Le flux multicast aller a cessé
Queue BFD en expiration Ce BFER n’a pas reçu le contrôle attendu Tous les récepteurs sont privés de flux
Nouveau UMH choisi La sélection a changé pour ce flux et ce BFER La continuité applicative est rétablie
Le secours émet Une deuxième source a démarré Les doublons sont filtrés partout

Une preuve utile conserve donc les deux extrémités dirigées, le sous-domaine, le traitement du paquet de test, l’entropie éventuelle, le discriminateur, l’intervalle de détection et la classe de trafic. Un événement Down détaché de ces champs est facile à automatiser et impossible à interpréter correctement après l’incident.

Le retour Ping peut donner deux faux verdicts

Le cas du Ping est encore plus net. Le BFER envoie une requête vers BFIR1. Plusieurs réponses manquantes suffisent à considérer BFIR1 comme UMH défaillant et à choisir BFIR2. Or le service circule dans le sens inverse, de BFIR1 vers le BFER.

Dans une topologie asymétrique, les deux trajets peuvent diverger. Le texte cite explicitement le faux négatif — le Ping échoue alors que le flux fonctionne — et le faux positif — le Ping répond alors que le chemin multicast est en défaut. Il demande que la requête soit co-routée avec le chemin du flux surveillé afin d’améliorer la cohérence.

Le verbe « améliorer » est important. Le co-routage rapproche la sonde du fait qu’elle prétend mesurer; il ne prouve pas que l’application a reçu un flux complet, ordonné et sans doublon. Ce dernier constat appartient au récepteur et à la couche applicative.

Froid, chaud et actif déplacent le risque

Le projet général sur la redondance des entrées multicast distingue veille froide, veille chaude et veille active.

En veille froide, le récepteur ne demande le flux au secours qu’après sa décision. La bande passante n’est pas dupliquée, mais la signalisation et la convergence peuvent perdre des paquets.

En veille chaude, le primaire et le secours connaissent déjà la demande; seul le primaire émet normalement. Le secours démarre plus vite, mais il peut disposer d’un pouvoir de relève fondé sur une observation qui ne couvre pas le chemin vers le récepteur.

En veille active, les deux entrées émettent et le BFER rejette le flux non sélectionné. Le temps de commutation peut diminuer, au prix d’une consommation permanente de bande passante et d’une fonction de sélection déplacée vers chaque récepteur.

Ce ne sont pas trois degrés d’une même solution. Ce sont trois répartitions différentes de l’état, du coût, de la perte acceptable et de l’autorité. Une exigence d’achat limitée à « basculement rapide » ne dit pas qui absorbe les doublons ni qui peut se tromper.

Une décision peut être locale à un seul BFER

Les BFER peuvent retenir des S-BFIR différents. Ils peuvent aussi appliquer des délais différents. À un instant donné, l’un peut avoir commuté, un autre maintenir BFIR1, et un troisième être encore en attente. L’événement minimal n’est donc pas primary_failed, mais un tuple comprenant flux, récepteur, BFIR sélectionné, chemin observé, détecteur, seuil et version d’état.

La réception d’un paquet depuis BFIR2 après la relève prouve seulement que BFIR2 a émis et qu’un paquet est arrivé. Elle ne prouve pas que BFIR1 s’est arrêté, que tous les BFER ont convergé, que la suppression de doublons a fonctionné ou que le lecteur vidéo n’a rien perdu.

Un reçu de relève doit joindre : identité du flux; S-BFIR et B-BFIR; BFER concernés; mode de veille; protocole d’overlay; chemin de mesure; preuve de co-routage; discriminateur et temporisation; acteur qui a autorisé le changement; ancien et nouveau UMH; démarrage et arrêt effectifs des deux sources; compteurs de perte, doublon et réordonnancement; résultat au récepteur; résultat applicatif.

Ce que le projet ne prouve pas

La révision 11 est un document de groupe de travail BIER, daté du 1er octobre 2026 et annoncé comme Informatif. Elle n’est pas un RFC. Elle ne demande aucune allocation IANA. Sa section de sécurité renvoie aux documents BIER, BFD multipoint, MVPN, Ping et BFD sous-jacents.

On peut donc attribuer au texte une analyse claire du risque de mauvaise observation. On ne peut pas lui attribuer un déploiement, une interopérabilité, un équipement conforme ou une reprise de service réelle.

Les couches de réalité de Lu Heng invitent à ne pas transformer l’état symbolique du détecteur en état physique du réseau. Le miroir des politiques demande ensuite de nommer celui qui peut transformer ce signal en changement de topologie, sa règle, son périmètre et sa conséquence.

Sources