Résumé

  • La RFC 3137 conservait le router-LSA et les coûts ordinaires des liens stub, mais portait les liens non-stub à 0xFFFF afin que les chemins redondants évitent le routeur sans perdre ses propres préfixes.
  • Ce signal exprimait une préférence, pas une disparition ni la preuve d’un drainage achevé. Sans itinéraire de remplacement, les versions plus récentes d’OSPF pouvaient encore employer ce chemin très coûteux.

Un nœud pouvait perdre un rôle sans perdre son adresse

Le problème apparaissait au moment où un routeur devenait fragile mais pas absent. Une charge CPU excessive, une mémoire insuffisante pour conserver les LSA ou une opération de maintenance pouvaient justifier qu’il ne transporte plus le trafic des autres. Pourtant, il fallait encore joindre ses interfaces, surveiller son état ou atteindre les réseaux qui lui étaient directement attachés.

Retirer son router-LSA aurait donné une réponse brutale. Dans OSPF, une route résulte d’un graphe partagé. La RFC 2328 construit d’abord l’arbre des routeurs et des réseaux de transit, puis ajoute les réseaux stub comme des feuilles. Si le LSA du routeur X disparaît, ses liens et les retours nécessaires au calcul disparaissent aussi. X n’est plus un passage, mais il risque également de ne plus être une destination calculable.

La RFC 3137, mémo Informationnel publié en juin 2001, conserva donc le nœud dans la topologie. Elle ne déclara pas que X avait cessé d’exister. Elle modifia le prix de ses rôles.

Deux catégories de liens, deux affirmations

Dans le router-LSA de X, tous les liens non-stub recevaient la valeur maximale sur seize bits, 0xFFFF. Le texte l’appelait LSInfinity, en la distinguant de la valeur maximale sur vingt-quatre bits des LSA summary et AS-external. Les liens stub de type 3 gardaient le coût de sortie normal de l’interface.

Le choix n’était pas décoratif. Les liens non-stub participaient au chemin qui traverse un routeur ou un réseau de transit. Avec le coût maximal, un chemin redondant devenait préférable. Les liens stub représentaient les préfixes directement rattachés comme des feuilles. Leur coût normal préservait le calcul d’une route vers la surface propre de X.

Le même document disait alors deux choses cohérentes : le routeur et ses préfixes existent encore ; ne faites pas du routeur un corridor si une autre voie est disponible. La joignabilité du nœud ne garantissait ni sa santé complète, ni sa capacité à reprendre le transit.

Cette nuance servait lors d’une introduction progressive, d’un retrait, d’un état critique ou d’une décision administrative. Elle ne transformait pas l’activation de la commande en constat d’exploitation. L’opérateur devait encore vérifier que l’annonce avait circulé, que les calculs SPF avaient changé et que les flux avaient réellement quitté le boîtier.

La redondance donnait sa force au signal

La RFC avertissait que le gain supposait au moins un certain degré de redondance. Un métrique élevé ne crée pas un lien de secours. Chaque routeur récepteur lit le LSA, applique son propre calcul et choisit parmi les chemins que la topologie lui offre.

Il faut donc éviter le mot « retrait » quand il laisse entendre une interdiction absolue. 0xFFFF était l’entrée la moins désirable du calcul, mais pas nécessairement une impossibilité pour les comportements issus de la RFC 1583. Si X constituait l’unique passage vers certains réseaux, ces routeurs pouvaient encore le sélectionner. Le réseau protégeait la continuité au prix d’un possible retour de charge sur le nœud dégradé.

La preuve opérationnelle se répartissait. Une configuration prouvait une intention locale. Le LSA émis prouvait un message. Les bases de données distantes prouvaient sa réception. Les tables de routage et de transfert montraient la décision prise. Les compteurs de flux montraient le transit restant. Une sonde de service testait encore autre chose. La RFC ne permettait pas de fondre ces reçus en un seul succès.

Une ancienne et une nouvelle lecture de la valeur maximale

Le mémo conserva une difficulté historique. Un calcul conforme à la RFC 1247 écartait les liens dont le coût valait LSInfinity. La RFC 1583 et les versions suivantes ne traitaient plus la valeur maximale comme totalement inatteignable.

S’il existait une route alternative, les deux familles préféraient l’autre chemin : leur divergence ne compromettait pas l’objectif. Si X était la seule voie, l’ancien comportement refusait son transit tandis que le plus récent pouvait l’utiliser à coût extrême.

La RFC 3137 affirma que cette différence précise ne produisait pas de boucle dans le scénario décrit. Cette phrase doit rester à sa place. Elle n’atteste pas qu’un changement de métriques est exempt de toute micro-boucle transitoire, que tous les logiciels se comportent pareil ou qu’une séquence de maintenance entière est sûre. La RFC 6976 traitera plus tard l’ordre des mises à jour FIB comme un problème séparé.

La compatibilité révèle aussi pourquoi LSInfinity était un nom imparfait. Une valeur que certains rejetaient pouvait rester un coût fini pour d’autres. Le mécanisme de 2001 vivait précisément sur cette frontière.

RFC 6987 clarifia sans effacer l’idée

En 2013, la RFC 6987 rendit la RFC 3137 obsolète. Elle conserva la technique, mais nomma la constante MaxLinkMetric. Le nom ne promettait plus une impossibilité universelle : il disait exactement qu’il s’agissait du plus grand coût architectural de lien, 0xFFFF.

La révision couvrit OSPFv2 et OSPFv3. Pour OSPFv3, elle ajouta l’alternative du bit R. Effacer ce bit exclut le routeur du transit de façon cohérente. L’opérateur choisit alors entre deux politiques : le métrique maximal peut laisser passer le trafic si aucune autre voie n’existe ; le bit R privilégie l’exclusion, même si elle rend des destinations inaccessibles par cette voie.

Il ne faut pas attribuer ces précisions rétrospectivement au texte de 2001. Elles montrent plutôt que la distinction initiale—rester joignable sans être le passage préféré—avait survécu assez longtemps pour réclamer un vocabulaire plus net.

« Gracieux » pouvait viser le résultat opposé

La RFC 3623 sur le redémarrage gracieux d’OSPF cherchait à maintenir un routeur dans le chemin de transfert pendant que son logiciel de routage redémarrait, sous des hypothèses strictes : état de transfert conservé, topologie stable et voisins capables d’aider. La RFC 3137 demandait au contraire aux voisins de contourner le routeur tout en continuant à le joindre.

Les deux mécanismes réduisaient la violence d’une transition, mais ils n’accordaient pas la même autorité au transit. Les confondre peut faire exactement l’inverse de l’objectif opérationnel.

La RFC 5817 traita ensuite l’arrêt planifié dans les réseaux MPLS/GMPLS à ingénierie de trafic. La RFC 6976 décrivit un cadre d’ordonnancement des FIB pour limiter les boucles pendant la convergence. Ces textes voisins n’élargissent pas la portée de la RFC 3137. Son LSA à coût maximal restait un signal de préférence OSPF ; il ne constituait ni un reçu de démontage de tunnel, ni une approbation de maintenance, ni une garantie de convergence sans boucle.

La présence n’était pas la disponibilité

Le geste historique le plus fécond fut de refuser le bouton unique « up/down ». Un routeur pouvait parler assez pour rester dans la base, être joignable pour l’administration et manquer pourtant de ressources pour porter le transit. À l’inverse, il pouvait publier le bon LSA sans que tous les récepteurs aient convergé ni que sa charge ait diminué.

Les autorités demeuraient séparées. X contrôlait son annonce. Chaque autre routeur contrôlait son SPF et son FIB. La topologie contrôlait l’existence d’un détour. L’opérateur décidait du moment d’entrée et de sortie. Les mesures prouvaient les effets.

La RFC 3137 ne revendiquait même pas l’originalité de l’idée. Elle n’apportait pas une histoire de déploiement. Elle fixa une primitive de coordination : enlever au routeur la fonction de route, sans lui enlever son identité topologique. Ce petit intervalle entre être là et servir de passage devint un espace exploitable pour changer le réseau sans le rendre aveugle.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3137.txt
  2. https://www.rfc-editor.org/info/rfc3137
  3. https://datatracker.ietf.org/doc/rfc3137/
  4. https://www.rfc-editor.org/rfc/rfc2328.txt
  5. https://www.rfc-editor.org/rfc/rfc1247.txt
  6. https://www.rfc-editor.org/rfc/rfc1583.txt
  7. https://www.rfc-editor.org/rfc/rfc6987.txt
  8. https://www.rfc-editor.org/info/rfc6987
  9. https://www.rfc-editor.org/rfc/rfc5340.txt
  10. https://www.rfc-editor.org/rfc/rfc3623.txt
  11. https://www.rfc-editor.org/rfc/rfc5817.txt
  12. https://www.rfc-editor.org/rfc/rfc6976.txt