L’IETF approuve l’inondation dynamique à titre expérimental. « Acceptable » reste à mesurer

Résumé

• Le 31 août 2026, l’IESG a approuvé la révision 05 de Dynamic Flooding on Dense Graphs pour publication comme RFC expérimental. Aucun numéro de RFC définitif ne figurait encore dans le dossier examiné.
• Un « Area Leader » calcule un graphe clairsemé pour diffuser l’état des liens, tandis que le graphe physique complet reste disponible pour l’acheminement des données.
• Le texte exige notamment trois mises en œuvre indépendantes et interopérables avant une éventuelle progression. Le dossier d’approbation n’en recense qu’une, pour IS-IS.
• Les critères parlent de convergence, de réduction, de qualité opérationnelle et de robustesse « acceptables » sans imposer de chiffres universels. Chaque opérateur doit donc déclarer ses mesures avant de connaître le résultat.
• Un registre d’expérience versionné doit conserver le code testé, les deux graphes, les choix de calcul, les pannes injectées, le mécanisme de repli et l’autorité ayant accepté ou refusé le déploiement.

Une autorisation d’essayer, pas un brevet de production

La nuance est inscrite dans le statut choisi. L’IESG a retenu la voie expérimentale après un consensus solide au sein du groupe Link State Routing. Le problème est concret : sur un graphe dense, la diffusion classique des changements d’état peut multiplier les transmissions redondantes. L’algorithme proposé demande à un nœud élu, l’Area Leader, de calculer un sous-graphe plus économe pour ces annonces.

Le trafic utilisateur ne bascule pas sur ce sous-graphe. Le réseau conserve son graphe de base pour l’acheminement ; seule la distribution des informations d’état emprunte la topologie calculée. Celle-ci doit couvrir tous les nœuds joignables, rester biconnexe lorsque c’est possible, ne pas allonger démesurément les chemins de diffusion et éviter de charger toujours les mêmes routeurs.

Dans l’exemple pédagogique du document, dix nœuds entièrement connectés représentent 45 arêtes. Le sous-graphe retenu n’en utilise que 12, au prix d’un diamètre qui passe de un à quatre. Cette image montre le compromis. Elle ne mesure ni un réseau d’opérateur, ni son temps de convergence, ni sa résistance à une succession de pannes.

Le choix de l’Experimental tient aussi à l’état du code. Le shepherd mentionne une seule mise en œuvre IS-IS, alors que le changement est important et s’appuie sur le cadre lui-même expérimental de la RFC 9667. Les auteurs ne revendiquent pas l’optimalité de leur algorithme. Ils proposent de construire l’expérience nécessaire à une décision ultérieure.

Le mot « acceptable » change de propriétaire

La révision 05 énonce sept conditions avant toute progression : au moins trois mises en œuvre indépendantes capables d’interopérer, une expérience documentée en exploitation, l’absence d’objection fondamentale, une révision convaincante des considérations de sécurité, une qualité opérationnelle acceptable, une convergence et une réduction de diffusion acceptables, enfin une robustesse face aux changements de topologie.

Cette liste protège le débat contre une démonstration trop facile. Trois paquets commerciaux fondés sur le même code ne constituent pas trois implémentations indépendantes. Un résultat de laboratoire ne devient pas une expérience opérationnelle parce qu’il porte le nom d’un grand réseau. Et l’interopérabilité doit se vérifier là où elle compte : le leader encode la topologie selon la RFC 9667 et chaque nœud interprète correctement son rôle.

Reste le vocabulaire. « Acceptable » n’a pas la même valeur dans un cœur d’opérateur, une fabrique de centre de données et une plate-forme d’essai. Imposer une latence unique ou un pourcentage uniforme aurait quelque chose d’artificiel. Le texte laisse donc de l’espace à la décision locale.

Cet espace devient dangereux si le seuil est choisi après la mesure. On peut alors célébrer une moyenne tout en écartant la queue de distribution où se trouve l’incident ; présenter une baisse de messages sans compter les nœuds anciens qui continuent à tout diffuser ; ou rebaptiser succès un résultat inférieur à l’objectif initial. La liberté locale n’est crédible que si la règle et son propriétaire précèdent l’observation.

Deux essais identiques en apparence peuvent ne pas l’être

L’algorithme central contient des choix laissés à l’implémentation : profondeur de parcours, ordre des voisins, départage des égalités et sélection d’arêtes supplémentaires. Ces décisions peuvent produire des graphes différents sur la même topologie. La mention « dynamic flooding activé » ne suffit donc pas pour comparer deux essais.

Il faut également rendre visible le rôle du leader. Quel routeur a été élu ? À partir de quelle vue de la base d’état des liens a-t-il calculé ? Quand son annonce est-elle devenue active ? Comment le changement de leader a-t-il été observé ? Le document souhaite qu’un mécanisme de gestion expose le leader et les adjacences de diffusion actives, mais en laisse la forme à chaque mise en œuvre.

Le déploiement partiel brouille encore la mesure. Les nœuds qui ne prennent pas en charge le mécanisme continuent à diffuser sur toutes leurs interfaces. C’est une propriété de compatibilité utile, mais aussi un élément du dénominateur. Annoncer le gain du seul groupe équipé revient à mesurer une zone autre que celle réellement exploitée.

Enfin, une topologie stable est le test le moins exigeant. Une perte de lien, la disparition d’un nœud, une partition ou un changement de leader déclenchent recalcul et diffusion temporaire. Une mauvaise transition peut priver une partie du réseau d’un état récent et conduire à des routes incohérentes. Le nombre moyen de messages n’explique pas ce moment-là.

Un registre d’expérience avant le premier résultat

Le registre devrait d’abord identifier l’objet testé : révision du draft, niveau de prise en charge de la RFC 9667, nom et version de la mise en œuvre, maturité, mode de licence, responsable et période. Une déclaration de propriété intellectuelle est liée à ces travaux ; son existence entre dans la décision de l’opérateur, sans que l’article prétende en déterminer la portée juridique.

Il devrait ensuite figer le terrain : empreinte du graphe de base, nombre de nœuds et d’arêtes, participants compatibles ou anciens, leader et méthode d’élection, empreinte du graphe calculé, paramètres de parcours et règles de départage. Des pseudonymes stables peuvent protéger les adresses et noms sensibles tout en permettant la reproduction.

Viennent les mesures : début et fin exacts de la convergence, volume de diffusion et interfaces comptées, charge par nœud, diamètre, distribution des degrés, pertes ou doublons, intervalle d’observation et seuil qui sépare réussite, réserve et échec. Les distributions complètes et les essais rejetés comptent autant que la moyenne.

Le volet résilience décrit à l’avance les événements injectés : perte de lien, perte de nœud, disparition du leader, partition puis réunification, changements rapides, coexistence avec des nœuds anciens et retour à la diffusion classique. Chaque ligne associe détection, activation du secours, remplacement du graphe, cohérence observée, délai de rétablissement et intervention humaine.

Enfin, le registre conserve la décision : poursuivre, limiter, suspendre ou revenir en arrière ; l’autorité qui tranche ; le seuil invoqué ; les exceptions et la date de réexamen. Une correction doit s’ajouter à l’historique, pas effacer un graphe qui a échoué.

La RFC 7942 fournit un précédent utile pour suivre l’état du code, sa maturité, sa couverture, sa compatibilité, sa licence et les tests d’interopérabilité. Ces faits vieillissent, raison pour laquelle ils ont besoin d’un registre vivant à côté d’un RFC immuable.

Ce que la décision ne démontre pas

Aucune source examinée n’établit trois mises en œuvre indépendantes, un déploiement de production nommé ou un gain mesuré sur le terrain. Aucun incident n’est attribué à l’algorithme. L’exemple à dix nœuds ne doit pas être converti en promesse commerciale.

Le parcours de la revue opérationnelle doit lui aussi rester précis. La revue OPSDIR de la révision 04 signalait des lacunes importantes sur le déploiement progressif, la coexistence d’algorithmes et les défaillances de nœuds. La révision 05 a ajouté une section consacrée aux considérations opérationnelles. Cela prouve que l’examen a influencé le texte, pas que toute question future est close.

La discipline de spécification minimale défendue par Heng Lu sert ici de test limité : le mécanisme partagé peut rester déterministe et vérifiable, tandis que les choix futurs conservent un propriétaire local. Elle ne fournit aucun fait sur cette approbation ni sur un réseau particulier.

L’IETF a donc créé un cadre commun pour apprendre. Le prochain acte de gouvernance n’est pas de déclarer la technologie acceptable, mais de publier les conditions qui permettront de l’affirmer ou de la refuser.

Sources

1. IESG — annonce d’approbation
2. IETF Datatracker — Dynamic Flooding on Dense Graphs, révision 05
3. IETF — rapport du shepherd
4. OPS Directorate — revue de la révision 04
5. RFC 9667 — cadre de l’inondation dynamique
6. RFC 7942 — suivi du code existant
7. IETF — déclaration IPR 4044
8. Heng Lu — Minimum Initial Specification