Summary

  • Le 21 septembre, l'IESG a approuvé draft-ietf-bier-ping-29 pour la voie Proposed Standard ; ce n'est pas encore un RFC publié.
  • Une requête Echo destinée à surveiller un flux doit reprendre son BIFT-id, sa longueur de chaîne de bits, son Entropy et son DSCP. Le traceroute de ce texte est limité au BIER sur MPLS, contrairement au ping.
  • Au 24 septembre, l'action de l'IANA se poursuit et la file du RFC Editor attend une intervention des auteurs. Le communiqué ne revendique qu'une mise en œuvre partielle et non précisée.

Le problème d'un réseau BIER ne se résume pas à la présence d'une réponse. Un paquet entrant peut être répliqué vers plusieurs routeurs de sortie, désignés par les bits de son en-tête. Une branche peut fonctionner pendant qu'une autre échoue. C'est précisément pour examiner ce plan de transfert sans prendre un test IP pour substitut que le groupe de travail BIER a proposé son mécanisme OAM.

L'IESG a approuvé le projet le 21 septembre. Cette décision donne une trajectoire normative au format des messages et à la détection des défauts. Elle ne certifie pas que chaque équipement sait envoyer toutes les requêtes, produire toutes les réponses ou restituer la même carte d'un incident. Il faut encore demander ce que le test a effectivement traversé.

Le texte apporte une réponse concrète : pour le flux surveillé, la requête Echo reprend BIFT-id, BSL, Entropy et DSCP. L'identifiant de table, la taille de la chaîne, le paramètre de répartition et la classe de traitement ne sont pas de simples annotations. Sans eux, une sonde « verte » peut emprunter des conditions différentes de celles du trafic qui a motivé l'enquête. Un tableau de bord devrait conserver ces valeurs avec le résultat, ainsi que les BFER ciblés.

Le titre réunit deux fonctions, pas deux portées identiques

Le mode traceroute défini ici ne couvre que BIER sur MPLS. Le ping n'a pas cette restriction. Cette phrase du projet devrait accompagner tout engagement de compatibilité. « BIER Ping and Trace pris en charge » est une étiquette trop large si l'encapsulation, le mode de réponse et la version logicielle restent inconnus. Même avec une réponse valide, la preuve porte sur le paquet OAM et le contexte effectivement testés, pas sur la livraison applicative ni sur la perte de tous les destinataires.

L'absence de réponse réclame autant de prudence. Elle peut signaler un défaut de transfert, mais aussi un chemin de retour indisponible, une limitation de débit ou une fonction non implémentée. Mélanger ces issues conduit à transformer une mesure en verdict.

La publication du protocole a, elle aussi, plusieurs étapes. Le projet demande notamment un port UDP pour une réponse Echo encapsulée en IP/UDP et des identifiants ou registres BIER OAM. Les commentaires de l'examen IANA distinguent clairement la réponse unicast dans un environnement contrôlé d'un transport de charge utile multicast. Il serait donc erroné de déduire du vote un numéro de port final ou une permission générale d'exposer ce service.

Au moment de la vérification, le Datatracker indique une entrée dans la file du RFC Editor, une action IANA en cours et un blocage « Author Input Required ». L'annonce de l'IESG demande aux auteurs de répondre aux questions IANA. Cela ne retire rien à l'approbation ; cela empêche seulement de raconter la file d'attente comme un travail achevé. La rubrique qualité du communiqué dit qu'une partie du mécanisme a été implémentée par des fournisseurs BIER, sans documenter les combinaisons testées.

Le principe de Lu Heng selon lequel la procédure technique doit rester soumise à l'épreuve des réseaux en fonctionnement sert ici de grille éditoriale, non de preuve d'un déploiement BIER. La question d'actualité est le passage entre décision, registres, RFC et essais reproductibles. Notre précédente couverture de la sonde CoS examinait une autre limite : ce qu'un résultat permet d'inférer sur un service.

Sources