Résumé

  • Dans un modèle BGP-LS-SPF clairsemé, la session qui transporte une Link NLRI n’emprunte pas nécessairement le lien de fabric qu’elle décrit. La découverte et la détection de vitalité restent des fonctions extérieures à BGP.
  • Une arête exploitable par SPF résulte d’une chaîne : observation locale, origine autorisée, version et état, éventuelle attente EoR, annonce inverse concordante, calcul local, programmation et preuve dans le plan de données.
  • L’authentification du réflecteur et la fraîcheur du message protègent le transport et l’ordre. Elles ne transforment pas le distributeur en témoin du fait physique.

Le contrôleur ne se trouve pas au bord du câble

Dans un fabric dense, un réflecteur reçoit deux descriptions d’une liaison entre une feuille et une épine. Il les propage à des dizaines de routeurs. Son canal TCP reste disponible pendant une panne partielle. Les compteurs de session sont normaux, la dernière séquence est bien la plus élevée et le calcul SPF se termine. Pourtant, un sens de la liaison ne transmet plus.

La tentation consiste à appeler cette situation une incohérence de BGP. Ce serait aller trop vite. Le réflecteur n’était pas placé au bord du câble. Il n’avait ni mandat ni instrument pour éprouver ce sens de transmission. Il a rempli son rôle : recevoir une affirmation, la classer et la diffuser. Le défaut vient du passage non documenté entre l’observateur du lien et l’auteur de cette affirmation.

La RFC 9815, publiée en juillet 2025 dans la voie normative, introduit la SAFI BGP-LS-SPF 80. Elle conserve l’automate, les messages et le transport du BGP de base, mais remplace le processus de décision pertinent par un calcul de plus court chemin sur des NLRI de nœud, de lien et de préfixe. La RFC 9816 décrit l’application aux fabrics Clos : lorsque 32, 64 chemins ECMP ou davantage relient les étages, il n’est plus nécessaire d’établir une session BGP sur chaque liaison.

L’économie de sessions est tangible. L’économie de preuve ne l’est pas.

La session et le fabric dessinent des cartes différentes

Avec une session EBGP à un saut sur chaque connexion point à point, le graphe de transport des annonces ressemble au graphe de transfert. L’établissement de la session et la négociation de la famille BGP-LS-SPF peuvent alors faire déclarer disponible le lien correspondant. La chute de la session retire ses NLRI de lien.

La séparation commence dès que deux routeurs directement reliés utilisent leurs adresses de loopback, ou lorsqu’ils ne parlent qu’à un réflecteur ou à un contrôleur. Plusieurs liens peuvent partager une session. Dans le scénario contrôlé de la RFC 9816, les nœuds du fabric peuvent même établir des sessions multihop vers deux contrôleurs ou davantage. La route suivie par ces sessions doit être trouvée autrement ; ce problème demeure hors du document.

La RFC 9815 place donc la découverte et la vitalité des liaisons hors de BGP dans ces modèles. Elle recommande BFD, qui vise à détecter rapidement une défaillance sur le chemin entre moteurs de transfert. Elle n’impose pas que BFD soit l’unique témoin. LLDP, des signaux de couche liaison, une fonction matérielle ou un dispositif spécifique peuvent participer selon l’architecture.

Le choix local ne dispense pas de préciser la portée. Une session BFD peut viser une interface, un faisceau, un tunnel ou un chemin multihop. Elle possède ses propres discriminants et temporisations. Une valeur Up n’est recevable comme entrée de la Link NLRI que si l’exploitant sait exactement quelle arête et quel sens elle couvre. Sinon, on économise des sessions BGP en créant une dette d’identité au niveau des liens.

Deux inventaires sont indispensables : le graphe de fabric et le graphe de diffusion. Leur table de correspondance doit indiquer, pour chaque arête, le détecteur, le routeur d’origine, les canaux de propagation et les consommateurs du calcul. Sans cette jointure, une carte lumineuse n’est qu’un dessin institutionnel de la réalité.

Une affirmation directionnelle, pas une vérité globale

Une Link NLRI BGP-LS-SPF appartient à un nœud local. Les descripteurs identifient l’origine et le voisin distant ; la métrique décrit le côté sortant. Le voisin produit sa propre annonce pour l’autre sens. Le réflecteur conserve et répète ces objets directionnels, mais ne prend pas possession de leur contenu.

La séquence sur 64 bits rend l’ordre explicite. Elle est obligatoire, strictement croissante pour chaque nouvelle version auto-originaire et doit rester croissante au cours de la vie du routeur, y compris après un redémarrage à froid grâce aux mécanismes disponibles. Des règles spéciales permettent aux voisins directs de purger une ancienne version lorsqu’un nœud a perdu son état de séquence.

Cet ordre résout une question : quelle version est la plus récente ? Il n’en résout pas une autre : l’observation sous-jacente était-elle exacte ? Un détecteur associé à la mauvaise interface peut faire naître une annonce fausse et parfaitement récente. Un pair autorisé mais compromis peut également publier une topologie modifiée. La sécurité doit donc conserver séparément l’identité de l’émetteur, l’origine revendiquée, l’empreinte du contenu, la séquence et la preuve de vitalité.

La RFC traite la double origine du même objet comme le signe possible d’une erreur de configuration ou d’une usurpation. La bonne réaction n’est pas de choisir mécaniquement le message arrivé par le plus grand nombre de chemins. Plusieurs copies du même mensonge ne constituent pas plusieurs témoins.

EoR ferme un transfert, pas un circuit

La marque End-of-RIB occupe une place délicate. Pour BGP-LS-SPF, un opérateur peut exiger l’EoR d’un pair avant d’annoncer la Link NLRI correspondant à ce pair. Si l’option de configuration existe, elle doit être cohérente dans le domaine. Lorsqu’elle est activée, l’attente indéfinie est la valeur par défaut ; un délai maximal peut être proposé.

Cette attente protège la préparation. Un routeur qui vient d’établir sa session peut ne pas avoir reçu assez d’état initial pour transférer correctement. Déclarer trop tôt son adjacence attire du trafic vers un nœud dont la table est incomplète. La RFC avertit qu’une configuration EoR incohérente peut provoquer des micro-boucles et des pertes transitoires.

Dans l’exemple contrôleur, celui-ci peut attendre l’EoR de chacun des deux pairs et recevoir la Link NLRI de chacun avant de libérer le lien vers le reste du domaine. Le geste est prudent, mais sa sémantique doit rester étroite. EoR indique la fin d’un transfert initial pour une famille d’adresses. Il ne mesure ni la continuité du câble, ni le fonctionnement des ASIC, ni un aller-retour de données.

Il faut donc refuser la colonne unique « prêt ». Une exploitation vérifiable distingue : session établie, capacité négociée, EoR reçu, détecteur local acceptable, annonce locale fraîche, annonce distante fraîche, paire réciproque admise, calcul achevé et transfert testé.

L’arête doit revenir sur elle-même

Le calcul SPF ne construit pas son graphe à partir de flèches isolées. Pour chaque lien du nœud courant, il cherche chez le nœud distant une Link NLRI qui pointe en retour. Pour un lien numéroté, les adresses locale et voisine doivent se croiser correctement. Les états du nœud et du lien doivent aussi permettre le transit.

Les liens non numérotés montrent toute la valeur de cette réciprocité. Ils utilisent les identifiants Local/Remote et un descripteur de famille d’adresses. Sans ce dernier, le lien n’entre dans aucun calcul IPv4 ou IPv6. Il est possible d’annoncer des descripteurs distincts pour les deux familles. Si l’identifiant distant est inconnu, la valeur zéro agit comme joker ; en présence de liens parallèles, ce compromis peut conduire les deux routeurs à ne pas désigner temporairement la même liaison opérationnelle.

L’erratum vérifié 8835 corrige justement la seconde moitié du test de la section 6.3. Le texte publié répétait la correspondance Remote-vers-Local. La lecture corrigée exige aussi que le Local du lien courant corresponde au Remote du lien inverse. Ce n’est pas la preuve d’une panne de produit. C’est la démonstration qu’un accord entre deux noms de nœuds ne suffit pas : il faut raccorder les deux extrémités de la même paire directionnelle.

L’EID 8836 a une portée différente. Il remplace le nom TIME_TO_LEARN par TIME_TO_LEARN_INTERVAL, conformément à la RFC 8405. Classer les deux corrections sous un même indicateur « deux bugs » masquerait la différence entre une condition d’identité et une harmonisation terminologique.

La négation doit circuler avant l’effacement

Lorsqu’un lien tombe, attendre que sa dernière copie soit retirée peut laisser une ancienne version positive participer au calcul. La RFC 9815 recommande alors à l’origine d’annoncer d’abord une version plus récente, marquée « link unreachable with respect to BGP SPF », puis de retirer l’objet. Le délai LinkStatusDownAdvertise suggéré est de deux secondes. Si le lien revient pendant cette fenêtre, une version encore plus récente sans l’état Down doit être publiée.

Ce mécanisme donne priorité à une négation ordonnée sur des copies positives plus anciennes. Il ne promet pas un rétablissement en deux secondes. La latence complète comprend la détection, l’origination, la diffusion, l’ordonnancement SPF, la modification de RIB/FIB et l’effet sur les paquets. La RFC 8405 rappelle en outre que réagir immédiatement à chaque événement peut accroître le churn, tandis qu’un back-off trop long maintient des vues divergentes.

Un journal sérieux relie donc les horloges au lieu de les additionner sous l’étiquette « convergence ». La RFC 9815 recommande des traces contenant le NLRI déclencheur, les heures de programmation, de début et de fin de SPF, l’état de back-off et des compteurs. Ajoutez-y l’événement du détecteur, le chemin de propagation, le diff de FIB et des sondes de transfert.

Transportable ne signifie pas calculable

La gestion des erreurs conserve une autre frontière utile. Une annonce privée d’attribut BGP-LS après un Attribute Discard peut rester conservée et propagée, mais elle ne doit pas être utilisée par SPF. Un TLV d’état ou de famille d’adresses mal formé entraîne un traitement treat-as-withdraw. Compter les objets reçus sans montrer leur admissibilité au LSDB donne une vision faussement complète.

Si deux bases de topologie BGP-LS-SPF se désynchronisent, la RFC exige la réinitialisation de la session, sauf mécanisme alternatif de resynchronisation. Elle définit le code de notification ; elle ne définit pas comment la perte de synchronisation sera détectée. Le contrôle dépend encore d’une observation locale que le protocole ne fabrique pas.

TCP-AO protège la relation avec le pair et réduit l’usurpation. Il ne garantit pas qu’un pair légitime soit sain ni que son capteur concerne le bon lien. L’authentification répond « qui m’a remis ce message ? ». La provenance répond « qui pouvait affirmer cette arête ? ». La preuve de transfert répond « que s’est-il passé dans le fabric ? ».

Un essai qui force les frontières à apparaître

Avant d’élargir un déploiement clairsemé, construisez un domaine de test où le graphe de sessions diffère du fabric et où deux liens non numérotés parallèles existent. Établissez une base : observations bilatérales, identifiants exacts, EoR conforme, graphes admissibles identiques et trafic sur chaque membre ECMP.

Coupez ensuite un seul sens sans interrompre la session vers le réflecteur. Vérifiez quel détecteur change, quel nœud fait avancer la séquence, quand l’état Down atteint chaque consommateur, quand la paire réciproque cesse d’exister et quand le prochain saut disparaît du matériel. Le rétablissement doit utiliser une version plus récente, jamais la résurrection d’un ancien enregistrement.

Répétez avec le descripteur de famille absent, les identifiants inversés, le joker zéro, des métriques différentes, un EoR retardé, un attribut supprimé, une double origine, une perte d’état de séquence, une base désynchronisée et un réflecteur indisponible. La RFC 9816 avertit également que des filtres BGP donnant des ensembles de NLRI différents aux routeurs peuvent produire des routes inaccessibles ou des boucles.

Conservez pour chaque test l’identité de l’arête, la portée et la génération du détecteur, le contenu exact du NLRI, son origine, sa séquence, son état, les pairs traversés, l’EoR, la raison d’admission ou d’exclusion, la génération LSDB, les temps SPF, les changements RIB/FIB, les sondes et le résultat du retour arrière.

C’est la primauté du code exécuté au sens de Heng Lu : non pas préférer une console au texte, mais rendre le passage de la spécification au paquet reproductible.

Limites de l’enquête

Les sources ne documentent aucun déploiement nommé, aucune matrice de fournisseurs, aucune distribution de temps de convergence, aucune panne ni aucun incident de sécurité. Les gains décrits par la RFC 9816 sont des propriétés attendues de l’architecture, non des mesures universelles.

Le peering clairsemé n’est pas non plus un bien absolu. Sa valeur dépend de la redondance du graphe de diffusion, de la portée des détecteurs, de la cohérence des métriques et filtres, de la disponibilité des contrôleurs et de la capacité de l’équipe à diagnostiquer deux cartes. La norme laisse volontairement ces choix à l’opérateur. La spécification initiale minimale crée un langage commun ; l’adoptant conserve la décision et la charge de preuve.

Sources

  1. Dossier Datatracker de la RFC 9815
  2. Historique de la RFC 9815
  3. Références de la RFC 9815
  4. RFC 9815
  5. Errata de la RFC 9815
  6. Rendu informatif avec errata
  7. RFC 9816
  8. RFC 9552 : BGP-LS
  9. RFC 5880 : BFD
  10. RFC 4724 : EoR et redémarrage gracieux
  11. RFC 8405 : back-off SPF
  12. RFC 7606 : traitement des erreurs UPDATE
  13. RFC 5925 : TCP-AO
  14. Heng Lu : Running-Code Primacy
  15. Heng Lu : Minimum Initial Specification
  16. Heng Lu : On Reality Layers
  17. Documents référençant la RFC 9815
  18. Fiche d’information de la RFC 9815
  19. Fiche d’information de la RFC 9816
  20. RFC 4271 : BGP-4