Résumé

  • RFC 5286 autorise un reroutage local rapide seulement lorsqu’un voisin est démontré sans boucle pour la destination et la panne considérées. Une activation globale ne garantit donc ni candidat ni couverture universelle.
  • Le dossier probant doit conserver la version de topologie, les opérandes, l’origine du préfixe, la classe de protection et l’état réellement installé. Un pourcentage sans dénominateur et sans hypothèse de panne n’est pas auditable.

Deux écrans, deux vérités

Le premier écran est celui de la configuration. Une case est cochée : la fonction LFA est active sur le routeur ou l’interface. Le second est une table de calcul : destination, prochain saut principal, voisin candidat, trois distances, tests complémentaires, décision. La première ligne peut être verte alors que la seconde ne contient aucun candidat valable.

Il n’y a pas de contradiction. La configuration dit que le logiciel peut chercher un secours. Elle ne crée pas dans le graphe un chemin qui n’existe pas. RFC 5286 pose pour le routeur calculateur S, le voisin N et la destination D la condition suivante :

Distance_opt(N,D) < Distance_opt(N,S) + Distance_opt(S,D)

Le signe est strict. Si les deux côtés valent 20, le voisin n’est pas qualifié. Avec les informations détenues par S, il reste possible que le trafic revienne vers S. Remplacer mentalement < par ≤ transforme une preuve de non-boucle en espoir.

Une modification de métrique peut faire passer le côté gauche de 20 à 19 et changer la décision. Le voisin reste le même, mais la propriété calculée ne l’est plus. Elle appartient à une destination, à une base topologique, à un instant et à une hypothèse de panne. C’est pourquoi archiver uniquement le verdict « éligible » détruit une partie essentielle de la preuve.

La couverture est un ensemble, pas un bouton

RFC 5286 vise à réduire les pertes pendant la convergence distribuée. Le routeur prépare un prochain saut de secours et peut l’utiliser après détection d’une panne, jusqu’à l’installation d’un nouveau calcul SPF. Le calcul du secours ne modifie pas le prochain saut primaire normal.

Mais ce secours est calculé pour chaque destination. Un même voisin peut protéger le préfixe A et échouer pour le préfixe B. Une annonce multirattachée peut imposer de considérer plusieurs routeurs d’origine et leurs coûts. Pour OSPF externe, le type de route, l’ASBR et l’adresse de transfert interviennent. RFC 8518 a mis à jour la section consacrée à ces préfixes parce qu’une simplification acceptable dans un cas peut masquer une autre possibilité dans un autre.

Le mot « couverture » exige donc un dénominateur explicite. Compte-t-on les préfixes, les liens, les nœuds, les prochains sauts, les classes de destination ou le volume de trafic ? Un chiffre de 95 % peut décrire des réalités opposées si les cinq pour cent restants concentrent les services essentiels. Le chiffre doit aussi préciser s’il s’agit de protection de lien, de nœud, de groupe de risque local ou seulement de non-boucle élémentaire.

RFC 6571 étudie cette dépendance à la topologie. RFC 7490 introduit le LFA distant parce qu’un voisin physique approprié manque souvent dans certaines formes de réseau, en particulier les anneaux. Ces extensions ne rendent pas rétroactivement universel le résultat du calcul ordinaire. Elles prouvent au contraire qu’une absence de candidat est un état normal qu’il faut rendre visible.

Une protection de lien ne devient pas une protection de nœud

Passer l’inégalité de base signifie que le voisin n’enverra pas le paquet directement en boucle vers S dans le scénario couvert. Cela ne garantit pas que son chemin évite le voisin primaire E. Pour déclarer une protection de nœud, il faut une condition supplémentaire. Si un cas d’égalité laisse à N plusieurs chemins de coût identique, dont l’un traverse E, S ne contrôle pas le choix de N. RFC 5286 demande donc de ne pas attribuer la protection la plus forte sur la base d’une possibilité favorable.

La condition « downstream » est plus restrictive :

Distance_opt(N,D) < Distance_opt(S,D)

Elle impose que le voisin soit déjà plus proche de la destination. Cette discipline réduit certains risques de microboucle lorsque la panne réelle dépasse l’hypothèse, mais elle élimine aussi des candidats. Une politique plus prudente peut produire moins de couverture. Le paquet peut alors être abandonné plutôt que boucler : résultat cohérent du modèle, mais très différent d’une promesse de continuité.

Les segments de diffusion et NBMA ajoutent le pseudo-nœud du protocole de routage. Un voisin qui évite le routeur primaire peut encore être atteint par le même segment défaillant. Les groupes de risque partagés ajoutent d’autres exclusions. Une étiquette unique « LFA » ne dit pas lequel de ces tests a réussi.

Enfin, la panne observée peut être plus large que celle prévue. Un secours calculé contre la perte d’un lien ne porte pas automatiquement la preuve pour la perte du nœud, de deux liens simultanés ou d’un risque corrélé non modélisé. Le périmètre de la panne doit rester attaché au résultat.

Le registre de preuve

Un enregistrement exploitable commence par le routeur calculateur, la zone ou le niveau IGP, l’horodatage et l’empreinte de la base topologique. Il nomme la destination, le type de route, chaque origine pertinente, le prochain saut primaire et la ressource protégée. Pour chaque voisin candidat, il conserve les trois distances, le résultat strict, les tests de downstream, de nœud, de pseudo-nœud et de SRLG, puis la raison du rejet ou la classe de protection retenue.

Il précise aussi la granularité. RFC 7916 distingue notamment calcul par préfixe et approches plus agrégées. L’agrégation réduit l’effort mais peut cacher l’exception d’un préfixe multirattaché. Le calcul fin améliore la visibilité, à condition de pouvoir exporter et comparer ses résultats.

Ensuite seulement viennent les autres reçus : candidat sélectionné selon la politique, prochain saut de secours installé dans le plan de transfert, événement de détection, activation effective, compteurs de paquets, convergence et sortie du mode de réparation. Le détecteur peut être BFD ou un autre mécanisme ; sa notification ne prouve ni l’éligibilité du candidat ni son installation.

La chaîne utile est :

configuré -> éligible -> sélectionné -> installé -> activé -> trafic observé -> convergence

Une mesure applicative peut ensuite établir un résultat de service, mais elle appartient à une autre couche. La présente analyse s’arrête volontairement avant la thèse déjà publiée sur TI-LFA et la restauration de service. Ici, le problème est antérieur : le voisin ordinaire avait-il seulement obtenu l’autorisation mathématique de servir de secours ?

Ce qui demeure inconnu

Les RFC ne prouvent pas qu’un opérateur nommé utilise LFA, qu’un équipement particulier calcule correctement les distances ou qu’un réseau réel atteint un pourcentage donné. Un test échoué n’est pas une anomalie de produit. Un test réussi n’est pas un reçu d’installation. Un prochain saut installé n’est pas une preuve de trafic livré.

Les mécanismes ultérieurs — LFA distant, TI-LFA, Segment Routing ou RSVP-TE FRR — possèdent leurs propres conditions. On ne peut pas les invoquer comme solution implicite lorsqu’aucune preuve de configuration, de calcul et d’installation n’a été observée. Le bon état public est parfois « aucune alternative éligible dans cette topologie », non « protection probablement assurée ailleurs ».