Résumé

  • RFC 9692 réduit l’état dans les feuilles en propageant la topologie détaillée vers le nord et surtout des routes par défaut vers le sud. Une feuille « tombée » révèle l’exception cachée par cet agrégat.
  • La désagrégation positive attire le trafic vers les parents qui conservent le chemin et reste limitée à un niveau. La désagrégation négative retire les parents incapables et peut descendre jusqu’à la feuille qui choisit le plan.
  • La réception d’un Prefix TIE négatif ne prouve ni l’installation dans chaque FIB matérielle ni la livraison du service. Il faut conserver une chaîne de preuves distinctes.

Le scénario trompeur commence par un voyant vert. La route 0/0 ou ::/0 est encore là. Plusieurs chemins ECMP existent encore. Pourtant, un paquet destiné à une feuille précise peut être envoyé dans le seul plan qui ne sait plus la rejoindre.

RFC 9692, publié sur la voie normative de l’IETF en avril 2025, définit RIFT pour les topologies Clos et fat-tree. Son compromis est directionnel : les North TIE diffusent vers le nord les adjacences et préfixes détaillés ; vers le sud, les nœuds annoncent normalement leurs adjacences et des routes par défaut, complétées par des exceptions. La fiche du RFC résume cette combinaison comme état de liens vers les épines et vecteur de distance vers les feuilles.

Une feuille est dite « tombée » lorsqu’elle reste joignable depuis seulement une partie des nœuds Top-of-Fabric. Dans un fabric à plusieurs plans, la sélection du plan se produit souvent dès la feuille d’entrée. Corriger le problème uniquement au sommet arrive alors trop tard : l’information doit atteindre le point où ce choix est fait.

L’exception positive n’est pas l’exception négative

La désagrégation positive part d’un routeur qui peut encore joindre le préfixe affecté. Il annonce une route positive plus spécifique dans un South Prefix TIE. Le longest-prefix match attire le trafic vers les parents capables. L’annonce n’est pas transitive : le récepteur ne la reproduit pas automatiquement au niveau inférieur.

Cette solution suffit si l’ensemble des ToF capables couvre tous les nœuds concernés dans le plan en défaut. Elle limite la perturbation et l’état supplémentaire au voisinage de la panne.

La désagrégation négative traite les fabrics où cette couverture n’existe pas. Un ToF qui ne peut plus joindre la feuille annonce négativement ses préfixes. Le préfixe négatif n’est utilisable qu’à l’intérieur d’un agrégat positif plus court. Il hérite des next hops de cet agrégat, puis supprime les voisins qui ont annoncé l’exception. Le RIB conserve la route négative et les informations d’arbitrage ; le FIB doit recevoir les instructions positives restantes.

La propagation vers le sud exige deux conditions : aucun enfant n’annonce le préfixe et tous les parents l’ont annoncé négativement. Le nœud peut alors réémettre l’exception jusqu’à la feuille d’entrée. Quand un parent retire son négatif, la propagation transitive doit aussi être retirée.

RFC 9692 décrit deux déclencheurs. Au ToF, une vue complète obtenue à partir des North Node TIE, liens horizontaux compris, est comparée au calcul SPF vers le sud ; les feuilles absentes de ce dernier deviennent candidates. Plus bas, lors de l’attachement des préfixes, un routeur peut constater que toutes les sorties héritées de l’agrégat ont été élaguées par les annonces négatives. Ce sont deux calculs de contrôle, pas deux essais de livraison.

Six observations, pas un seul état « convergé »

La première observation concerne la panne elle-même : interface, expiration LIE ou détection BFD. RIFT peut intégrer BFD ; RFC 5880 et RFC 5881 encadrent cette détection bidirectionnelle rapide. Elle ne dit pas encore quels préfixes de feuille sont affectés.

Viennent ensuite la propagation des Node et Prefix TIE, le calcul fallen-leaf, l’émission et la réception du disagrégat, le résultat SPF/RIB, puis l’installation réelle dans le FIB matériel. RFC 9719 permet d’exposer la configuration et l’état RIFT — interfaces, voisins, bases TIE et statistiques SPF. Cette visibilité est précieuse, mais elle reste une vue du protocole de routage.

L’observation suivante traverse le plan de données. Une mesure active fondée, par exemple, sur le protocole bidirectionnel de RFC 5357 peut confirmer le chemin suivi par une sonde pendant un intervalle. Elle doit varier les feuilles d’entrée, les préfixes, les familles d’adresses et les hachages ECMP. Même réussie, elle ne garantit pas l’état de l’application, la capacité en charge ni chaque chemin alternatif.

RFC 9696 souligne que la désagrégation négative exige une connaissance complète des préfixes au ToF et que la programmation du FIB peut devenir récursive. Il rappelle aussi qu’ECMP ne garantit pas à lui seul livraison ou latence bornée. Ce texte d’applicabilité ne fournit aucun résultat de déploiement nommé.

Le registre des errata de RFC 9692 mentionne actuellement une correction technique tenue pour mise à jour, relative à du contenu Thrift omis en section 7.2. Elle ne modifie pas la mécanique fallen-leaf.

Les essais de Heng Lu sur la primauté du code en fonctionnement, la spécification initiale minimale et les couches de réalité servent ici d’optique éditoriale : règle, exécution et résultat doivent rester séparés. Ce ne sont ni des exigences IETF ni des preuves sur un réseau RIFT.

La conclusion est donc limitée : RFC 9692 fournit le langage de réparation. L’acceptation opérationnelle exige d’enchaîner panne détectée, TIE propagé, calcul vérifié, FIB installée, sondes réussies et service livré — puis de refaire le même parcours lors du retrait de l’exception.