Résumé

  • RFC 9494 prolonge la conservation de certaines routes au-delà du Graceful Restart ordinaire, par famille AFI/SAFI et pour une Long-Lived Stale Time négociée ; LLGR_STALE les rend visibles et moins préférées que toute route fraîche.
  • Enke Chen est coauteur de RFC 4724 et de RFC 9494. Cette filiation ne transforme pas un ancien chemin en vérité : plafond local, NO_LLGR, synchronisation End-of-RIB, retrait à l'expiration et avertissements sur les boucles gardent la continuité conditionnelle.

Conserver n'est pas confirmer

Une session BGP rompue retire au réseau sa source d'information nouvelle. Elle ne détruit pas forcément, au même instant, l'état déjà installé dans le plan de transfert. Un routeur peut avoir perdu son processus de contrôle tout en continuant à commuter des paquets. Un réflecteur de routes peut redémarrer sans que tous les chemins qu'il annonçait cessent physiquement d'exister. À l'inverse, la présence de ces anciens chemins dans une table ne prouve rien sur leur sort réel.

La décision comporte donc deux erreurs symétriques. Tout retirer immédiatement peut propager une panne de contrôle jusqu'aux services qui fonctionnaient encore. Tout conserver sans distinction peut prolonger un trou noir et lui donner l'apparence d'une stabilité. Le problème de LLGR n'est pas de choisir abstraitement entre disponibilité et exactitude. Il consiste à rendre mesurable la dette contractée lorsque l'on continue à transférer sur une information qui n'est plus actualisée.

Cette dette varie selon l'objet BGP. Une route unicast employée saut par saut dépend étroitement de l'état physique du prochain saut. Une information de découverte, un objet VPN ou un chemin transporté au-dessus de tunnels peut survivre différemment à la perte du dialogue de contrôle. Un seul délai universel serait donc moins une simplification qu'un refus de voir les domaines de panne.

La première grâce tient sur douze bits

RFC 4724, publiée en 2007, porte les noms de Srihari Sangli, Enke Chen, Ramachandra Fernando, John Scudder et Yakov Rekhter. Elle définit la capacité Graceful Restart de BGP et le marqueur End-of-RIB. Pendant un redémarrage, l'émetteur peut préserver son état de transfert ; le récepteur peut garder les routes apprises du pair et les déclarer stale en attendant la reconstruction du dialogue.

La durée n'est pas ouverte. Restart Time occupe douze bits, soit un maximum encodable de 4 095 secondes. Le texte recommande une valeur par défaut au plus égale au HOLDTIME annoncé dans OPEN. Si la session ne revient pas avant la fin du délai, les routes conservées doivent disparaître. Si le récepteur sait plus tôt que le transfert du pair n'est plus viable, il peut aussi les supprimer.

Pendant cette phase classique, la préférence des routes n'est pas réduite. C'est un pari bref : éviter des retraits massifs le temps que le contrôle revienne. RFC 8538 a ensuite autorisé la procédure pour d'autres modes de rupture, tout en créant un signal Hard Reset pour demander un redémarrage complet. Le perfectionnement ne retire pas la nécessité d'une fin explicite.

LLGR crée un autre rang de preuve

RFC 9494, publiée en novembre 2023, est signée par James Uttaro, Enke Chen, Bruno Decraene et John G. Scudder. Elle ne se contente pas d'agrandir le compteur de RFC 4724. Elle crée un deuxième régime dans lequel le caractère ancien de la route modifie sa place dans la sélection.

La capacité LLGR, code 71, contient des tuples <AFI, SAFI, Flags, LLST>. Chaque combinaison de familles peut recevoir sa propre Long-Lived Stale Time. Aucun défaut n'est recommandé : la bonne durée dépend de la fonction transportée, de l'échelle et des scénarios de panne. Le récepteur peut imposer une borne haute, une borne basse ou les deux, et réduire la valeur proposée par le voisin.

LLGR doit être accompagnée de la capacité GR ordinaire. Sans elle, le récepteur l'ignore, car les deux mécanismes partagent End-of-RIB, la logique de reconnexion et plusieurs transitions. Avec deux durées non nulles, elles se succèdent. Durant GR, la route reste stale sans déclassement. Dès que LLGR commence, elle devient un dernier recours. Un Restart Time égal à zéro permet de sauter la première phase.

Ce séquençage évite de confondre deux hypothèses. La courte fenêtre suppose que le pair va rapidement reconstruire une vue actuelle. La longue fenêtre accepte que cette reconstruction soit incertaine ; elle ne doit donc plus accorder à l'ancien état la même autorité qu'à une annonce fraîche.

La communauté qui transporte le doute

À l'entrée en LLGR, le helper démarre le minuteur propre à l'AFI/SAFI et ajoute LLGR_STALE, communauté bien connue de valeur 0xFFFF0006. La route marquée doit être moins préférée que toute route qui ne l'est pas. Si deux candidats sont tous deux au dernier rang, la sélection BGP habituelle les départage.

Le résultat est subtil. Une solution de remplacement fraîche l'emporte, même si les attributs ordinaires auraient favorisé l'ancien chemin. En l'absence de toute solution fraîche, la route stale peut toutefois rester la meilleure et continuer à transporter des paquets. RFC 9494 maintient une possibilité de service ; elle ne délivre pas de certificat de fonctionnement.

Le doute ne doit pas être perdu lors de la propagation. La route ne devrait pas être annoncée à un pair qui n'a pas déclaré la capacité LLGR, sauf dans la procédure facultative et circonscrite aux voisins internes ou de confédération. Si elle est réannoncée, LLGR_STALE reste attachée. Une information vieillie ne peut pas redevenir ordinaire en franchissant un routeur.

La communauté NO_LLGR, valeur 0xFFFF0007, ouvre la sortie inverse. Une route qui la porte ne doit pas être conservée selon LLGR. L'émetteur peut exclure un objet dont la survie serait dangereuse ; le récepteur peut produire la même décision par politique locale. La négociation de la capacité ne retire à aucun participant le droit de dire non pour une route donnée.

Le retour du pair ne remet pas l'horloge à neuf

Une connexion rétablie prouve que les deux processus peuvent de nouveau parler. Pour une famille donnée, elle ne prouve pas encore que toutes les annonces ont été rafraîchies. La synchronisation dépend du marqueur End-of-RIB ou de la limite de report de sélection. Le minuteur LLST continue jusqu'à cette frontière ; à son expiration, toute route encore stale est supprimée.

Cette règle compte particulièrement lors de redémarrages successifs. Sans elle, chaque nouvelle coupure pourrait renouveler indéfiniment un état jamais confirmé. RFC 9494 refuse ce rajeunissement administratif. L'absence des capacités attendues, de la famille ou du signal de préservation au retour du pair entraîne également le nettoyage.

L'exemple normatif de fonctionnement emploie une Restart Time d'une seconde et une LLST de 3 600 secondes. Après la première seconde, les routes du réflecteur reçoivent LLGR_STALE et sont déclassées. Faute d'alternative, le routeur de bord les utilise encore et peut les annoncer à un pair externe capable. À l'expiration, il les retire. Si la resynchronisation se termine après 180 secondes, les annonces fraîches perdent le marqueur. Le pair externe qui n'a jamais déclaré LLGR reçoit, lui, un retrait dès le début de la phase longue.

Une préférence basse ne corrige pas la topologie

Le premier danger vient de l'ordre des décisions. BGP choisit entre chemins pour un même préfixe ; le transfert IP choisit d'abord le préfixe le plus spécifique. Une route stale plus précise peut donc attirer les paquets avant qu'une route fraîche mais moins précise ne soit considérée. Le déclassement BGP n'empêche pas ce trou noir.

Le deuxième danger naît de décisions différentes à l'intérieur d'un AS. Dans l'exemple de RFC 9494, un routeur abandonne une sortie devenue least preferred, tandis qu'un autre continue à privilégier cette même sortie. Chacun envoie alors les paquets vers l'autre. Le mécanisme classique peut déjà créer des incohérences transitoires ; une durée longue transforme le transitoire en incident persistant.

La règle cardinale du document est donc nette : LLGR n'est pas recommandé pour des routes utilisées en transfert saut par saut au sein d'un AS. Les infrastructures tunnelisées et les objets BGP éloignés du prochain saut conventionnel présentent moins de risques, pas une absence de risques. Le F bit et l'état de transfert annoncé doivent correspondre à une conservation réelle, pas à une préférence commerciale pour de beaux indicateurs.

Les VPN ajoutent une contrainte de sécurité. Un label associé à une ancienne route peut être réattribué après retrait. Si l'ancienne annonce survit, des paquets peuvent atteindre un nouveau contexte avec un label dont le sens a changé. Le délai minimal de réutilisation des labels doit donc dépasser la borne maximale de LLST avant d'activer LLGR pour la famille VPN concernée.

Standardiser l'état, localiser l'acceptation

L'essai de Lu Heng sur la spécification initiale minimale, la décision future localisée et l'adoption volontaire fournit une lecture ultérieure utile. La couche commune peut se limiter à la négociation, au périmètre par famille, aux marqueurs de dégradation et de refus, au rang de sélection et à l'expiration. Le réseau qui supporte la perte conserve la décision sur les pairs admis, les plafonds, le mode de transfert et les causes d'arrêt anticipé.

Cette répartition n'autorise ni le centre ni la périphérie à réécrire le fait. Le protocole commun ne commande pas à tous de conserver. La politique locale ne peut pas retirer LLGR_STALE et présenter l'ancien comme du neuf. La norme rend l'état intelligible ; l'opérateur choisit s'il vaut le risque.

La primauté du code en fonctionnement impose ensuite la preuve : tuples réellement négociés, valeurs reçues et plafonnées, nombre de routes entrées en LLGR, changement de best path, retraits vers les pairs incapables, progression End-of-RIB, pertes, boucles et purge finale. Cette application est l'analyse ultérieure de Sofia Ren à partir de Lu Heng, non une opinion privée attribuée à Chen ou au groupe d'auteurs.

La force intellectuelle de RFC 9494 tient à une retenue : la route gardée reste stale. Elle peut acheter du temps, jamais effacer l'incertitude. L'apport documenté de Chen se lit dans cette discipline collective : faire survivre le transfert sans conférer au passé un droit illimité sur le présent.

Sources