Résumé

  • Le RFC 9917 est un Proposed Standard IETF publié en janvier 2026. Il met à jour les RFC 9350 et RFC 9843.
  • Son mécanisme est directionnel : le récepteur peut signaler une condition à l’extrémité distante, puis les informations d’Administrative Group inverses peuvent amener le calcul à exclure l’arête aller correspondante.
  • Le RFC ne détecte pas automatiquement une panne, ne rend pas un lien physique symétrique et ne prouve pas qu’une implémentation est déployée. La télémétrie, les seuils, l’encodage, l’ordre des règles et la compatibilité restent à établir.

Le mécanisme

Il faut distinguer l’arête orientée qui transporte le trafic et celle qui représente ce que voit l’autre extrémité. Le RFC 9917 décrit le cas où un récepteur détecte des erreurs d’entrée, les erreurs CRC n’étant que l’exemple donné par le RFC. L’opérateur peut définir un seuil ; lorsque la mesure le franchit, le récepteur peut positionner un Extended Administrative Group sur l’arête dirigée en sens inverse. Le Flex-Algorithm évalue alors cette affinité inverse pendant le calcul des chemins dans la topologie aller.

Le RFC ne fournit pas une valeur opérationnelle universelle. Il faut attribuer la responsabilité de la télémétrie, définir le moment où le signal est activé et celui où il est retiré, puis vérifier l’encodage. Des seuils de déclenchement et d’effacement distincts limitent le va-et-vient autour d’une valeur limite. La temporisation ordinaire du protocole IGP et la limitation du flooding peuvent aussi réduire les recalculs répétés. Elles ne déterminent toutefois pas les seuils sûrs pour une topologie donnée.

RFC 9917 définit, pour IS-IS et OSPF, trois familles de contraintes reverse Admin Group : exclude, include-any et include-all. Exclude rejette un candidat dont l’arête inverse porte un groupe interdit. Include-any exige au moins un groupe demandé ; include-all exige tous les groupes demandés. Les détails du sous-TLV et le comportement du récepteur comptent. Les longueurs mal formées des sous-TLV reverse-affinity sont ignorées, et les occurrences en double déclenchent les comportements prévus pour l’encodage IS-IS ou OSPF concerné. Il ne faut pas inventer une règle « la dernière occurrence gagne » ou une fusion automatique.

Un registre ordonné

Les nouvelles contraintes sont les règles de calcul 8, 9 et 10. Elles prolongent les règles de pruning ordonnées définies par les travaux Flex-Algorithm des RFC 9350 et RFC 9843. L’ordre fait partie du contrat : l’ordre relatif existant ne doit pas changer, et les règles ne peuvent être ni supprimées, ni fusionnées, ni répétées. Il faut donc vérifier le FAD gagnant et l’ensemble de la séquence, pas seulement la présence d’un champ reverse-affinity.

Les équipements mixtes constituent un risque. Le RFC 9917 n’impose pas que tous les routeurs prennent en charge toutes les contraintes Flex-Algorithm, et le paquet de faits ne permet aucune affirmation de déploiement par un fournisseur. Un FAD accepté syntaxiquement peut conduire à des élagages différents si la prise en charge, la gestion des doublons ou la validation de l’encodage divergent. Les tests doivent comparer les attributs aller et inverse, le FAD gagnant, la topologie élaguée et les phases d’activation comme d’effacement.

Analyse — Theo March

Le changement important est qu’un défaut de réception unidirectionnel peut devenir une entrée de politique de routage, sans prétendre que le lien sous-jacent est devenu physiquement symétrique. La capacité est donc utile seulement si toute la chaîne est gouvernée : télémétrie, seuil, groupe inverse, règles ordonnées et convergence. Une perte d’observabilité à un seul endroit transforme un signal pertinent en changement de topologie difficile à expliquer.

La décision n’est pas simplement « activer RFC 9917 ». Il faut activer une contrainte précise seulement si la responsabilité de la télémétrie est claire, si les seuils d’activation et d’effacement ont été testés, si l’encodage du RFC 7308 est validé, si le FAD gagnant et l’ordre des règles concordent, si la couverture de support est connue, si la convergence est mesurée et si le retour arrière est répété. Sinon, la fonction doit rester désactivée ou être limitée à un domaine expérimental.

Cette thèse ne se confond pas avec le rejeu PCEPS du RFC 9916, le cycle de vie des baux DHCPv6 du RFC 9915, la projection de routes RPL du RFC 9914 ou la récupération RAW du RFC 9912. Ici, le sujet est l’évidence directionnelle d’un lien comme entrée ordonnée du pruning IGP Flex-Algorithm.

Parcours de décision d’acceptation opérateur

  1. Nommer le responsable de la télémétrie du récepteur et documenter le signal d’erreur ; les CRC restent l’exemple du RFC, pas un détecteur universel.
  2. Choisir et tester des seuils distincts d’activation et d’effacement, puis mesurer le flooding et les recalculs sous bruit.
  3. Valider l’encodage Extended Administrative Group selon le RFC 7308, y compris les longueurs mal formées et les occurrences en double.
  4. Confirmer le FAD gagnant, les règles 8 à 10 et toutes les règles précédentes, sans changer, supprimer, fusionner ou répéter l’ordre du registre.
  5. Vérifier la prise en charge IS-IS et OSPF sur chaque nœud ; ne pas supposer une prise en charge universelle ni un déploiement fournisseur.
  6. Observer les attributs aller et inverse, le FAD, les chemins élagués, la convergence et le rollback. N’accepter qu’une chaîne explicable de bout en bout.

Registre des affirmations et des preuves RFC

Affirmation Preuve
Les Administrative Groups inverses peuvent élaguer une arête aller RFC 9917, résumé et sections 1, 3
Erreurs d’entrée distantes et signal inverse piloté par seuil RFC 9917, section 3
Exclude, include-any et include-all pour IS-IS et OSPF RFC 9917, sections 5–10
Longueurs mal formées et occurrences en double RFC 9917, sections 5–10
Modèle Flex-Algorithm et FAD gagnant RFC 9350
Règles de pruning antérieures et extensions RFC 9843
Encodage Extended Administrative Group RFC 7308
Règles 8, 9, 10 et ordre immuable RFC 9917, sections 11 et 12.3–12.3.1

Sources