Résumé

  • La RFC 9502 étend Flex-Algorithm au transfert IPv4 et IPv6 ordinaire, mais exige une suite de faits locaux avant qu’une entrée de transfert puisse exister.
  • La participation au plan de données IP est annoncée séparément de celle des plans Segment Routing. Un même numéro d’algorithme ne décrit donc pas à lui seul la portée effective d’un réseau.
  • La norme prévoit des refus vérifiables : des annonces incompatibles sont ignorées, un routeur sans FAD valide cesse de participer et une frontière de domaine peut interrompre la portée du calcul.

La confusion commence souvent dans une réunion de changement. L’équipe a choisi un identifiant Flex-Algorithm, les contrôleurs voient une définition cohérente et une carte colore plusieurs routeurs. La présentation peut alors conclure que le trafic applicatif suit désormais une politique de délai, de bande passante ou de résilience. Cette conclusion mélange trois preuves que la RFC garde séparées : ce que le domaine a décrit, ce qu’un routeur a calculé et ce que le trafic a réellement fait.

La valeur de la RFC 9502 est précisément de ne pas masquer ce travail. Elle amène les préfixes IPv4 et IPv6 dans la famille des calculs IGP Flex-Algorithm. Cela permet d’associer un préfixe à un algorithme et à une topologie, puis d’installer le résultat chez les routeurs capables et participants. Ce mécanisme n’est pas une promesse commerciale ni une autorisation générale de relabeller toute route comme « conforme ». C’est un contrat de calcul borné.

Une définition partagée n’est pas un trajet

La Flexible Algorithm Definition, ou FAD, porte les éléments communs : type de calcul, métrique et contraintes éventuelles. Selon la RFC 9350, les routeurs participant au même algorithme dans la même portée d’annonce doivent s’accorder sur cette définition afin de préserver un transfert sans boucle. Cet accord est important, mais il répond seulement à une question précise : les participants emploient-ils les mêmes règles de calcul ? Il ne dit pas que tous les routeurs participent, que tous les liens satisfont les contraintes, ni que la destination est joignable de bout en bout.

La participation est une seconde preuve. La RFC 9502 demande qu’elle soit signalée indépendamment pour le plan de données IP. Un routeur peut donc participer à un algorithme donné pour les préfixes IP sans participer à ce même algorithme pour Segment Routing, tout en restant participant à l’algorithme 0 par défaut. Cette séparation protège les opérateurs contre une inférence trop large : le numéro est partagé, les plans de données ne le sont pas nécessairement.

Il existe ensuite une troisième preuve, l’annonce de joignabilité du préfixe. Les nouveaux encodages IS-IS et OSPF relient un préfixe à une topologie et à un algorithme. Ils ne demandent pas au récepteur de croire tout ce qu’il voit. Dans les cas prévus où des originataires différents associent le même préfixe à des algorithmes différents, le récepteur doit ignorer les annonces et ne doit installer aucune entrée de transfert sur leur base. L’absence d’installation n’est pas un manque de données à maquiller ; elle est la réponse sûre à une contradiction.

Le calcul vient après. Pour l’IP Flex-Algorithm, les nœuds qui ne publient pas leur participation sont retirés de la topologie considérée. Le routeur calcule alors avec l’algorithme et la topologie associés au préfixe. L’entrée ne doit être installée que chez un récepteur capable qui participe effectivement à cette combinaison. Un non-participant ne doit pas l’installer. Une carte d’annonces, une table de calcul et une FIB sont donc trois surfaces d’observation, non trois noms pour le même fait.

Les refus de la norme sont des signaux utiles

Une architecture sûre ne transforme pas une information absente en valeur rassurante. La RFC 9350 impose à un nœud configuré de cesser de participer s’il ne trouve pas une FAD valide ou s’il ne prend pas en charge le type de calcul, la métrique, la contrainte, le drapeau ou le sous-TLV de la définition retenue. De même, une métrique requise mais non annoncée conduit au retrait du lien du calcul ; elle ne peut être assimilée à une métrique de zéro.

Ces conditions sont parfois présentées comme des fragilités de déploiement. Elles sont plutôt des frontières d’intégrité. Elles empêchent un domaine de proclamer un chemin contraint alors que les éléments nécessaires pour le calcul n’existent pas. L’équipe doit observer le retrait, comprendre sa cause et décider localement de corriger, de revenir en arrière ou de maintenir l’algorithme hors service. La norme ne délègue pas cette décision à un tableau de bord.

La frontière géographique ou administrative renforce ce point. Un ABR ou un ASBR choisit son prochain saut à partir de sa visibilité locale. La RFC 9350 avertit qu’au-delà d’une zone ou d’un domaine, le chemin peut devenir sous-optimal au regard des contraintes, et que le trafic peut être abandonné si le domaine suivant n’a pas de joignabilité pour l’algorithme. Une définition proclamée à l’entrée n’est donc pas une attestation de continuité dans chaque domaine ultérieur.

Le registre IANA apporte une quatrième distinction. Les valeurs 128 à 255 sont réservées aux Flexible Algorithms. Le registre stabilise l’interprétation d’une valeur ; il ne prouve ni configuration, ni diffusion, ni compatibilité, ni sélection de chemin. Un numéro alloué est un vocabulaire commun, pas un relevé d’exécution.

Produire une chaîne de preuve exploitable

Pour chaque changement, conserver la FAD réellement retenue, sa portée, les versions logicielles capables de l’interpréter et les écarts de support. Conserver séparément les annonces de participation au plan IP, les annonces de préfixe avec leur algorithme, les métriques et contraintes effectivement utilisées, ainsi que les raisons d’ignorance ou de non-installation. Une configuration voulue ne suffit pas ; il faut pouvoir montrer le résultat local de sa lecture.

Puis seulement vient la preuve de transfert. Une FIB montre une intention locale de transmettre. Elle ne montre pas un paquet. Les compteurs d’interface montrent une activité, pas la réponse d’un destinataire. Une réponse applicative appartient encore à une autre couche. Lorsqu’un objectif concerne une charge utile, il faut relier au même intervalle temporel la FAD, le calcul, le prochain saut, la FIB, les compteurs, l’observation de destination et le résultat applicatif. Chaque élément doit avoir un auteur technique et une condition de réfutation.

La grille de Lu Heng aide ici comme discipline éditoriale. La couche commune doit être stricte sur les règles qu’elle partage réellement. La décision ultérieure reste locale, tout comme le fonctionnement constaté. La RFC 9502 fournit les faits communs : définition, participation, association de préfixe, calcul et installation. Elle ne voit pas à elle seule le paquet d’un client, l’acceptation d’un service ou la valeur obtenue par l’utilisateur.

Sources