Résumé

  • draft-ietf-bier-bfd-12 applique le BFD point-à-multipoint à BIER. Un BFER qui ne reçoit plus les contrôles du BFIR envoie spontanément une notification unicast sur UDP 4784 par un chemin qui doit être disjoint de l’arbre multicast.
  • La réponse Final du BFIR clôt l’échange d’alarme. Elle ne localise pas la rupture, ne recense pas toutes les extrémités et ne prouve ni réparation de l’arbre ni livraison applicative.

Une extrémité ne reçoit plus les battements venus de la racine. Elle déclare Down, place Control Detection Time Expired dans le diagnostic et envoie son alarme par une route que le trafic multicast ne devait pas emprunter. La racine répond Final. L’incident, lui, peut continuer.

Cette succession est au cœur de la révision 12 de BIER BFD, publiée le 29 septembre 2026. Cet Internet-Draft Standards Track du groupe de travail BIER transporte le BFD multipoint sur un domaine BIER et reprend le mécanisme de notification spontanée de RFC 9780. Il expire le 2 avril 2027. Ce n’est pas un RFC, une attribution IANA, un produit ni un constat de déploiement. Les trois valeurs demandées restent TBD1, TBD2 et TBD3.

La perte observée ne va que de la tête vers cette extrémité

Le BFIR tient le rôle de MultipointHead. Il encapsule les paquets de contrôle BFD dans BIER à destination d’un ensemble de BFER. Chaque extrémité surveille ce flux et peut conclure que la continuité depuis la tête a expiré.

La phrase doit rester directionnelle. Elle signifie que ce BFER n’a pas reçu les paquets attendus pour cette session. Elle ne désigne pas un lien cassé, un routeur fautif ou une entrée de réplication. D’autres BFER peuvent continuer à recevoir normalement. Une expiration locale n’est donc ni une carte de panne ni un verdict global sur l’arbre.

La session peut être amorcée par BIER Ping, par un attribut BGP ou par configuration statique. Avec BIER Ping, le Target SI-BitString nomme les extrémités visées et un TLV proposé porte My Discriminator. L’amorçage doit identifier la racine et être repris si le discriminateur change. Il décrit le contexte prévu ; il ne prouve pas que toutes les extrémités ont installé la même session ni que chaque paquet courant a suivi l’arbre voulu.

Un nombre de quatre octets n’est pas une identité complète

Dans le BFD classique, Your Discriminator aide le récepteur à retrouver sa session. Une extrémité P2MP ne crée pas ce discriminateur distant de la même manière : elle reçoit le My Discriminator attribué par la tête.

Or ce nombre n’est unique que dans le contexte de cette tête. Le projet utilise donc le champ BFIR-id de l’en-tête BIER comme deuxième composante. À l’extrémité, la clé obligatoire devient (BFIR-id, My Discriminator).

Un journal qui ne garde que le discriminateur peut rattacher une alarme à la mauvaise racine. La preuve opérationnelle doit conserver aussi le sous-domaine, le jeu de cibles, l’identité locale du BFER, la méthode d’amorçage et l’historique des changements. La précision de l’identité protège la décision ultérieure ; elle n’est pas un embellissement de télémétrie.

Le signal de retour échappe au destin de l’arbre

Lorsqu’il détecte la perte, le BFER construit un paquet précis : Poll activé, état Down, diagnostic Control Detection Time Expired, et Your Discriminator égal au My Discriminator de la session défaillante. Il l’envoie à l’adresse du BFIR en IP/UDP unicast, port de destination 4784.

Le chemin doit être disjoint de l’arbre de distribution multicast. Cette exigence rend l’alarme observable quand le chemin surveillé ne l’est plus. Elle sépare aussi les preuves. Recevoir la notification montre que ce paquet unicast est revenu de ce BFER à ce BFIR. Cela ne révèle pas où le trajet BIER s’est rompu.

L’opérateur doit donc archiver deux provenances : la session BIER dont la continuité a expiré et la route unicast qui a transporté le rapport. Une disjonction logique ne suffit pas toujours ; des routes différentes peuvent partager une carte, une fibre, une alimentation ou une file de contrôle. Le projet pose la contrainte, mais ne réalise pas l’audit des domaines de panne.

Final accuse réception, il ne guérit rien

Le BFER émet une notification par seconde jusqu’à recevoir un paquet Final valide pour la session ou jusqu’à disparition du défaut. Il devrait aussi envoyer trois paquets à intervalles pseudo-aléatoires pendant une seconde afin d’améliorer la probabilité de remise.

Le BFIR associe le rapport grâce à Your Discriminator, puis répond en unicast avec le bit Final. C’est un reçu utile : la tête a reçu et reconnu l’alarme. Mais Final ne dit pas qu’un changement de route a été appliqué, que l’arbre est de nouveau sain ou que l’application reçoit son flux.

Même l’arrêt des répétitions est ambigu sans événement corrélé. Il peut venir de Final ou d’une disparition locale du défaut. L’automatisation doit distinguer « rapport accepté » de « incident résolu ». Accuser réception peut être immédiat ; autoriser une action exige une preuve indépendante de topologie, d’étendue et de politique.

Les extrémités silencieuses ne sont pas automatiquement saines

Une panne commune peut toucher beaucoup de BFER et provoquer une pointe de notifications vers le même BFIR. La révision 12 impose de contrôler le nombre de paquets remis au plan de contrôle. Cette protection évite la surcharge, mais elle crée son propre angle mort.

Une extrémité muette peut être saine, privée de continuité descendante, incapable de joindre le chemin retour, non configurée ou filtrée avant traitement. Une alarme reçue ne classe pas les autres. Il faut rapprocher les extrémités attendues, les tuples installés, les déclarations Down, les rejets à l’entrée, les rapports admis, les associations réussies, les Final envoyés et la continuité ensuite retrouvée.

La chaîne de preuve reste donc séquentielle : version exacte ; autorité d’amorçage ; identité composite ; dernier paquet valide ; expiration ; construction du rapport ; garde du chemin retour ; association par le BFIR ; Final ou fin du défaut ; réconciliation de la population ; diagnostic ; réparation ; retour du BFD ; observation applicative. Aucun maillon ne prête sa certitude au suivant.

Le principe de spécification initiale minimale de Heng Lu convient à cette architecture. La couche commune normalise l’identité, le signal, la répétition et l’accusé indispensables à l’interopérabilité. La sélection des extrémités actives, la véritable diversité, la protection du contrôle et l’autorité de réparation restent locales. Un brouillon publié n’est pas une adoption ; seuls le code en fonctionnement, les paquets et les résultats observés la démontrent.

Sources