Résumé

  • La version 12 de draft-ietf-bier-bfd, encore au stade de projet Internet en dernier appel du groupe BIER, décrit plus impérativement l'alerte non sollicitée d'une extrémité active. Pour cette application à BIER, elle s'appuie explicitement sur le mécanisme de la RFC 9780 et le distingue des méthodes sollicitées de la RFC 8563.
  • L'extrémité avertit la tête par IP/UDP unicast, sur un trajet séparé de l'arbre multicast, en désignant la session P2MP BFD défaillante. La réponse Final confirme un échange de notification lié à cette session; elle n'atteste pas, à elle seule, la réparation du chemin aller.

Dans un réseau multipoint, le premier témoin d'une rupture est souvent celui qui ne reçoit plus rien. Si une extrémité BFER cesse de voir les paquets de contrôle émis par le BFIR, elle peut déclarer la continuité perdue. Pourtant, le tableau d'alarme à la tête de l'arbre peut rester vide. Ce décalage n'est pas une anomalie logique: la détection en aval et la transmission de son résultat en amont utilisent des mécanismes différents.

Le texte du 29 septembre cherche à rendre cette jonction vérifiable. Selon l'IETF Datatracker, draft-ietf-bier-bfd-12 est un Internet-Draft actif du groupe BIER, en WG Last Call; son état IESG demeure I-D Exists. On ne peut donc ni le présenter comme une RFC adoptée, ni en déduire une panne observée chez un opérateur. Il spécifie la manière dont BFD point-à-multipoint pourrait s'appliquer aux chemins BIER.

Sur le sens aller, la RFC 8562 donne à chaque extrémité la possibilité de surveiller les paquets envoyés par la tête. Elle ne suffit pas à apprendre à cette dernière quelle extrémité a perdu le signal. La section 6 du nouveau projet retient, pour BIER, la notification spontanée de l'extrémité active décrite par la RFC 9780, par opposition aux échanges sollicités de la RFC 8563. La nuance historique compte: la version 11 du projet possédait déjà une sous-section consacrée à une notification non sollicitée, et la RFC 8563 évoque elle aussi de tels paquets.

La nouveauté de cette révision réside dans une dépendance mieux explicitée et des conditions de transmission rendues plus prescriptives.

Après la détection, le BFER doit envoyer un paquet BFD dont le bit Poll est actif, l'état vaut Down et le diagnostic indique Control Detection Time Expired. Le champ Your Discriminator doit contenir le My Discriminator de la session P2MP défaillante. Le paquet part vers l'adresse IP du BFIR, au port UDP 4784. La voie unicast de retour doit être distincte de l'arbre de distribution multicast: solliciter le chemin dont la continuité vient de disparaître ne constituerait pas une remontée indépendante.

Le projet exige un envoi par seconde jusqu'à ce qu'une réponse Final valable pour la session arrive ou que le défaut disparaisse. Il recommande aussi trois paquets espacés de manière pseudo-aléatoire dans un intervalle d'une seconde pour accroître la chance d'atteindre la tête. À l'arrivée, le BFIR utilise Your Discriminator pour retrouver la session; après correspondance, il retourne un paquet BFD unicast avec Final. Dans l'autre sens, l'extrémité reconnaît la session par le couple BFIR-id et My Discriminator de la tête. Un journal d'incident utile doit préserver ces liaisons, pas seulement une ligne générique « alerte BFD ».

La distinction décisive est temporelle. Une extrémité peut avoir constaté la panne sans avoir transmis l'avis; la tête peut avoir acquitté l'avis alors que le chemin multicast reste interrompu. Le texte mentionne aussi la poussée de notifications que plusieurs extrémités peuvent produire simultanément et la nécessité de limiter la charge du plan de contrôle. L'absence d'alerte à la tête ne prouve donc pas l'absence de perte en aval: c'est une déduction opérationnelle à partir des deux trajets et de leurs limites, non une statistique de terrain.

Le précédent article consacré à BIER Ping traitait d'un test diagnostique et de son parcours normatif; celui-ci porte sur la chaîne de preuve d'une surveillance continue.

Sources