Résumé

  • La signalisation de défaillance entre BFD et BGP repose sur une chaîne de documents : RFC 5880 et 5882 (2010), RFC 9384 (2023) et le draft strict-mode, encore en révision.
  • Chaque niveau de preuve — texte normatif, errata, rapports déclarés par les vendeurs, interopérabilité documentée, documentation de logiciels livrés — démontre quelque chose de différent sur la durabilité d'une réparation.
  • Aucun niveau disponible à ce jour ne prouve à lui seul qu'une réparation de détection de défaillance est durablement vérifiée.

Le texte normatif ne prouve rien sur les réseaux. Erratum 5205 contre la RFC 5880 documente un défaut de signalisation réel : après un AdminDown suivi d'une défaillance unidirectionnelle du lien, le système distant n'émite aucune indication de timeout dans ses paquets de contrôle. L'erratum est « held for document update » — le défaut est connu, documenté, mais non corrigé dans le texte publié.

L'erratum 7240, rapporté par Jeffrey Haas lui-même, présente une divergence différente : les notes concluent que le texte de la RFC est « correct, complete, and reflects the authors' intention », tout en documentant que plusieurs implémentations remettent bfd.LocalDiag à zéro au retour à l'état Up. C'est une divergence spécification/implémentation, pas un bug de la norme — et c'est précisément le type de fait que seul un inventaire d'implémentations peut révéler.

À l'autre extrémité de la chaîne, la RFC 5882 contient une référence croisée interne erronée (Section 3.2 au lieu de 4.2), corrigée par l'erratum 8921 vérifié par l'IESG (Ketan Talaulikar). La vérification IESG porte sur une citation, pas sur un comportement d'exécution — mais elle établit qu'un processus de vérification existe et fonctionne.

Le niveau des implémentations est dominé par l'auto-déclaration. Le rapport d'implémentation du sous-code BFD Down de la RFC 9384 liste deux implémenteurs conformants : Juniper 22.3R1 (contact : Jeffrey Haas) et Arista 4.29.0 (contact : Bill Fenner). Aucun test indépendant, aucune méthodologie publiée. Les diapositives d'interopérabilité de l'IETF 118 rapportent un échange réussi de la BFD Strict-Mode Capability (option 74) entre Junos et SRoS — tout en documentant une implémentation propriétaire qui exige une configuration statique des deux côtés et BFD Up avant la poignée de main TCP, qualifiée de compliquant le déploiement.

La documentation des logiciels livrés complète le tableau : Junos décrit le mode strict avec un intervalle d'attente (défaut 30 s, plage 10–255 s) et l'envoi d'une notification avec sous-code BFD Down à l'expiration ; FRR implémente « neighbor bfd strict [hold-time] ». Deux implémentations indépendantes documentées, mais toujours par leurs propres éditeurs.

Le cas le plus révélateur est la RFC 9978 (BFD Stability) : un mécanisme conçu précisément pour rendre la stabilité mesurable, publié sur la piste expérimentale parce qu'il n'existait « no known implementations or proof of concept ». La mesure de la durabilité reste, elle-même, non implémentée.

Sources