Résumé

  • L’IESG a approuvé draft-ietf-bier-ping comme projet de norme le 21 septembre 2026. La révision 29 attend le traitement du RFC Editor ; aucun numéro de RFC ni port définitif n’est présumé ici.
  • Packet-Forward-Success décrit ce que le BFER répondant a réussi à traiter. Lorsque plusieurs BFR-ID figurent dans une requête, ce code ne prouve pas que tous ont répondu.
  • Le dossier de mesure doit conserver le BitString original, les cibles successives, chaque réponse ou expiration, les codes, DDMAP, classes d’entropie et modes de retour, puis comparer séparément le trafic de production.

Une liste de destinataires ne se solde pas avec un seul reçu

Dans BIER, chaque bit positionne un routeur de sortie. Une même trame peut donc nommer plusieurs BFER sans que le cœur conserve un arbre multicast par flux. BIER Ping exploite cette propriété pour demander au plan de transfert ce qu’il a fait.

La date d’approbation est vérifiable dans les décisions de l’IESG. Le Datatracker place la révision 29, datée du 19 septembre, dans la file du RFC Editor. C’est un jalon normatif, pas une preuve de déploiement, et le texte final peut encore évoluer. Attribuer aujourd’hui un numéro de RFC ou un port définitif reviendrait à transformer une étape en résultat achevé.

Le risque opérationnel apparaît lorsqu’un outil résume toute la transaction par « réussi ». Un BFER peut retourner légitimement Packet-Forward-Success pour son traitement local. Ce constat vaut pour ce répondant, cette recherche et ce paquet. Si un autre bit n’a produit aucune réponse, le code positif ne l’efface pas.

La révision 29 reconnaît ce cas : l’absence d’un BFR-ID est difficile à détecter lorsque la requête en contient plusieurs. Le diagnostic peut exiger une nouvelle requête ne laissant que la sortie muette. La complétude n’est donc pas contenue dans un message ; elle se construit par rapprochement.

Le Target BitString transforme le test en séquence

Le texte distingue l’Original SI-BitString de la sélection opérée par le Target SI-BitString. Après la réponse d’un BFER, l’initiateur peut retirer son bit des requêtes suivantes. Un essai fiable commence avec une liste immuable et se termine quand chaque bit attendu possède soit une réponse attribuée, soit un délai expiré explicite.

Cela impose de conserver l’état intermédiaire. Six sorties attendues, cinq réponses et un silence non isolé ne forment pas un succès. Une sonde mono-cible vers la sortie manquante permet de resserrer l’enquête. Même alors, le silence ne nomme pas sa cause : transfert aller, sélection de cible, analyse du paquet, envoi au processeur, création de la réponse, chemin retour ou limitation de débit restent possibles.

Le mode de retour est une autre frontière. Une réponse IP/UDP prouve le retour d’un message par IP ; elle ne teste pas un trajet BIER retour. Une réponse BIER peut exercer cette direction. Ni l’une ni l’autre ne démontre que l’application multicast a reçu ou décodé une charge utile de production.

Quatre codes, quatre constats locaux

Packet-Forward-Success confirme le traitement réussi du chemin répondant. No matching entry in the forwarding table situe un échec de recherche local. Set-Identifier Mismatch révèle une discordance susceptible de faire franchir une limite de sous-domaine. DDMAP Mismatch confronte la projection aval attendue et celle du transfert ; boucle ou duplication deviennent alors des hypothèses structurées.

Réduire ces codes à un booléen détruit leur valeur. Il faut les attacher au BFR-ID, aux BitStrings entrant et sortant, à l’interface aval, au DDMAP, au SI et au contexte d’étiquette. Le contrôle plane peut alors être comparé au comportement observé au lieu d’être confondu avec lui.

L’ECMP exige une matrice, pas une moyenne

Pour BIER sur MPLS, la procédure multipath du projet cible un BFER précis et renvoie un masque d’entropie associé aux chemins aval. Une demande multipath portant sur plusieurs BFER n’est pas valide. Cette restriction sépare deux affirmations : « la sortie a répondu » et « les branches pertinentes vers cette sortie ont été exercées ».

Chaque sortie critique nécessite donc sa propre liste de classes d’entropie, d’exécutions et de chemins constatés. BFIR-id, BitString, BIFT-id, longueur du BitString, SI, entropie et DSCP doivent également correspondre au traitement que l’on prétend mesurer. Une sonde placée dans une classe différente peut réussir pendant que le flux réel échoue.

RFC 10014 encadre la méthode OAM active ; RFC 9974 énonce les exigences OAM de BIER. Ensemble, ils renforcent la discipline du test. Ils n’autorisent pas à confondre paquet construit, santé durable du service et résultat client.

Un policer peut fabriquer du silence

Le protocole atteint le plan de contrôle. Le projet recommande donc de limiter le débit vers ce plan et vers le port consacré. Cette protection est nécessaire, mais elle signifie qu’un manque de réponse peut venir du dispositif d’observation lui-même.

Le manifeste doit joindre débit offert, compteurs de punt et de policer, erreurs d’analyse et charge du répondant. Sinon, l’équipe risque soit de modifier un transfert sain, soit de relever aveuglément une limite et d’ouvrir une voie d’épuisement du plan de contrôle.

La hiérarchie de réalité décrite par Heng Lu aide à maintenir l’ordre des preuves : l’approbation est un fait de processus ; le draft décrit des symboles ; une configuration expose une capacité ; la campagne observe un comportement ; la livraison applicative demeure une autre couche. BIER Ping gagne en autorité lorsque chaque affirmation reste dans sa couche.

Sources