Résumé

  • La révision 02 de draft-ietf-bfd-rfc5883-bis remplace l’interdiction absolue de l’écho BFD multihop par une règle conditionnelle : interdiction si un retour intermédiaire est possible, permission uniquement si l’environnement l’empêche.
  • Le texte reste un Internet-Draft de groupe de travail. Le tableau d’implémentation HPE nouvellement ajouté est une déclaration de contributeur non vérifiée, et non la preuve que la règle est déployée ou interopérable.

Recevoir une réponse ne prouve pas toujours que le chemin a été testé. Dans un parcours à plusieurs sauts, un routeur intermédiaire peut renvoyer un paquet Echo avant qu’il n’atteigne l’extrémité visée. La session paraît alors vivante, tandis qu’une partie du trajet reste inconnue.

C’est la raison donnée par le RFC 5883, publié en 2010, pour interdire sans exception la fonction Echo de Bidirectional Forwarding Detection sur plusieurs sauts. La révision 01 du projet de remplacement conservait cette formulation. La révision 02, mise à disposition le 19 août, la rend dépendante du contexte de transmission.

Le nouveau paragraphe maintient un MUST NOT lorsque l’encapsulation ou le transfert peut amener un nœud intermédiaire à renvoyer le paquet vers l’émetteur. Il ajoute un MAY seulement lorsque l’environnement garantit que cela ne se produira pas. Une encapsulation faisant suivre au paquet une route explicite est citée comme exemple, pas comme recette universelle.

La portée est donc précise. Le projet n’approuve pas l’écho multihop en général. Il déplace la question vers une propriété vérifiable : le paquet a-t-il nécessairement traversé l’intégralité du chemin avant de revenir ? Sans cette preuve, la réponse Echo conserve exactement l’ambiguïté qui avait motivé l’interdiction.

Une comparaison structurée des deux versions montre que ce paragraphe est le seul changement normatif du corps du texte. La révision 02 ajoute aussi un état d’implémentation fourni par HPE, aux côtés d’une contribution ZTE déjà présente. Ces informations aident le groupe de travail à examiner la faisabilité, mais ne mesurent ni un déploiement ni une interopérabilité.

HPE qualifie de « Mature » une implémentation propriétaire Junos OS BFD Implementation et déclare prendre en charge les chemins arbitraires, l’encapsulation et l’authentification. La signalisation hors bande du discriminateur et les liaisons unidirectionnelles ne sont que partiellement prises en charge, uniquement sur des LSP MPLS. Aucune expérience d’exploitation n’est fournie.

Le préambule de la section est explicite : l’IETF n’a pas vérifié les données fournies par les contributeurs, une mention n’est pas une approbation et la liste n’est pas un catalogue. Les intitulés de maturité ne doivent donc pas être transformés en certification publique.

La révision précédente contenait déjà une déclaration ZTE décrivant un mode Echo non affilié, avec les paquets placés dans un Segment Routing Header, et indiquant que l’écho pouvait alors franchir plusieurs sauts. Cette déclaration coexistait avec l’interdiction normative absolue. Le nouveau texte résout cette tension par une condition d’environnement, mais aucune source n’attribue formellement la modification à ZTE.

Le projet compagnon sur l’usage générique de BFD a lui aussi atteint la révision 02 le même jour. Son ajout substantiel est un autre tableau HPE/Junos : couverture large déclarée, mais absence d’implémentation des OSPF Virtual Links et aucune expérience d’exploitation fournie. Il peut servir à comparer les revendications génériques et multihop, pas à conclure qu’elles fonctionnent entre produits indépendants.

Les deux textes sont encore des Internet-Drafts actifs du groupe BFD. Les pages Datatracker du projet multihop et du projet générique affichent l’état IESG I-D Exists. Ils ne remplaceraient les RFC 5883 et 5882 qu’après approbation.

Les autres limites restent intactes. BFD est un mécanisme d’exploitation, d’administration et de maintenance du réseau, non un contrôle de santé application-à-application à travers l’Internet. Une cadence mal dimensionnée peut provoquer de la congestion et de fausses détections. Plus le nombre de sauts augmente, plus la surface d’usurpation s’étend ; le recours à une authentification cryptographique forte demeure donc important.

Aucune source officielle de cet ensemble de révisions ne montre que la nouvelle condition Echo a été activée dans un produit, testée entre fournisseurs ou mesurée en production. La prochaine preuve utile n’est pas un simple paquet revenu à son point de départ : c’est une trace démontrant qu’il a atteint l’extrémité et qu’aucun changement de route ou d’encapsulation ne permet un retour prématuré.

Sources