Résumé

  • RFC 9107 autorise un route reflector à calculer le coût intérieur depuis une position IGP configurée pour un client, un groupe ou l’ensemble du réflecteur, plutôt que depuis sa position physique.
  • « Optimal » reste étroit : le résultat est celui que cette perspective choisirait parmi les mêmes candidats éligibles, sous la politique configurée. Une topologie périmée ou un candidat absent change la réponse.
  • Un déploiement sûr prouve l’affectation des racines, l’époque topologique, la complétude des candidats, le budget de calcul, la bascule de secours, l’Adj-RIB-In du client et la FIB.

Prenons un route reflector virtuel dans un centre de données qui sert des routeurs situés dans trois villes. Deux border routers annoncent le même préfixe. Les attributs BGP prioritaires sont à égalité ; le tie-break atteint le coût IGP. Pour un client à l’est, la première sortie est proche. Pour le réflecteur, installé à l’ouest, la seconde l’est davantage.

Le réflecteur pose une question parfaitement valide : quel next hop est le plus proche de moi ? Il choisit la sortie occidentale et la reflète à tous. Le client oriental ne voit jamais l’autre candidat. Ses paquets traversent le backbone vers une sortie optimale uniquement pour un calculateur qui ne les transporte pas.

Chaque composant peut pourtant être correct. L’IGP mesure bien les liens, BGP suit son Decision Process, la session reste stable. L’erreur porte sur le point d’observation. Un algorithme exact exécuté depuis le mauvais lieu produit fidèlement la mauvaise réponse pour son utilisateur.

RFC 4456 reconnaît ce prix du scaling. Un réflecteur résume l’information et n’envoie normalement que son best path. Comme les coûts IGP varient d’un routeur à l’autre, certaines topologies de réflexion ne reproduisent pas les décisions d’un full mesh. La solution traditionnelle rapproche la topologie des reflectors de celle du forwarding.

La centralisation a distendu ce lien. Un vRR peut vivre hors du data path, à l’endroit commode pour le compute. Sa position IGP devient alors une entrée accidentelle du traffic engineering. Déplacer le service de contrôle peut déplacer les sorties sans modifier ni les routes externes ni la politique des clients.

RFC 9107 remplace cette position accidentelle par une racine logique. L’opérateur choisit un nœud de la topologie link-state, identifié par une adresse telle qu’une loopback. Le reflector construit un shortest-path tree depuis ce nœud et utilise le coût vers les next hops candidats au moment de la comparaison IGP.

La racine est un regard, pas un passage. Les paquets ne la traversent pas nécessairement. Le BGP next hop, sa résolution récursive et la FIB du client forment le chemin physique. Confondre l’adresse de racine avec un waypoint transforme une donnée de calcul en fausse description du trafic.

La granularité est configurable : une perspective par reflector, par groupe de clients ou par client. RFC 9107 n’exige d’une implémentation conforme que la prise en charge d’au moins une catégorie. La conformité ne promet donc pas automatiquement la précision individuelle.

Chaque granularité est une approximation. Une racine globale coûte peu mais peut répéter le biais historique. Une racine par région représente le centre du groupe et non chaque bord. Une racine par client est plus précise et multiplie les SPF ainsi que des portions du Decision Process. « Toujours choisir le mode le plus fin » n’est pas une politique de capacité.

Le mot optimal doit rester borné. Dans la modification de base, ORR substitue le coût depuis la racine choisie à l’étape e du tie-break de Phase 2 de RFC 4271. Les préférences appliquées plus tôt continuent de dominer. Une local preference supérieure peut l’emporter sur une sortie IGP bien plus proche.

Le coût IGP n’est ni la latence, ni la congestion, ni le prix du transit, ni le risque de maintenance. ORR facilite le hot-potato routing lorsque la politique antérieure laisse plusieurs candidats à égalité. La formulation exacte est « sortie la plus proche sous cette métrique et après cette politique », pas « meilleur chemin global ».

RFC 9107 peut aussi exécuter plus qu’un tie-break différent. Si des groupes ont des politiques BGP différentes, une portion plus large, voire la totalité du Decision Process, peut être répétée. L’affectation d’un client à un groupe devient alors une délégation de perspective topologique et commerciale.

Cette affectation est un objet de production. Déplacer un client entre deux groupes peut modifier des milliers d’Adj-RIB-Out sans nouvel UPDATE externe ni changement de lien. Le mapping nécessite version, reviewer, rollout borné et diff exact, au même titre qu’une route policy.

Le calcul suppose enfin que tous les candidats pertinents arrivent au reflector. Un SPF parfait ne peut sélectionner une route absente. RFC 9107 demande que les reflectors apprennent tous les chemins éligibles et indique qu’ADD-PATH doit être déployé entre eux pour atteindre ce résultat entre clusters.

Une capability ADD-PATH ne suffit pas. Le sens doit correspondre pour l’AFI/SAFI, la politique d’ensemble du sender doit inclure le candidat, et l’import doit le conserver. L’Adj-RIB-In du point de calcul est la preuve minimale. Une perspective correcte appliquée à un univers incomplet reste fausse.

ORR déplace la dépense. Envoyer plusieurs chemins à chaque edge laisse les clients choisir, mais augmente RIB et updates distribués. ORR garde un ensemble plus riche au centre, calcule pour chaque perspective et envoie un résultat réduit. L’économie d’état en périphérie concentre information, CPU et confiance sur les reflectors.

L’entrée topologique doit être prouvée avec la même exigence. RFC 9107 cite IS-IS, OSPF et BGP-LS. Une base link-state présente peut être vieille, limitée au mauvais area ou level, divergente entre deux reflectors, ou dépourvue de la racine attendue. « Database reçue » ne signifie pas « vue correcte ».

BGP-LS peut transporter la topologie vers un calculateur, sans garantir la fraîcheur du consumer. Il faut l’époque, la couverture attendue, la santé des sessions sources et un rapprochement avec l’IGP des routeurs de forwarding. RFC 7752 ayant été remplacé par RFC 9552, l’architecture réelle doit identifier la spécification et le comportement qu’elle utilise aujourd’hui.

La récursion du next hop ajoute un piège. Lorsque le BGP next hop est lui-même joint par une route BGP, RFC 9107 veut le coût IGP final après résolution. Si l’implémentation ne peut pas fournir ce coût, elle doit traiter ces chemins comme les moins préférés pendant cette comparaison, tout en les conservant valides pour Phase 2. Une route valide peut donc perdre parce que le calcul ne voit pas jusqu’au bout.

Les limites de produit sont propres aux plateformes. Junos documente des contraintes lorsque la résolution primaire utilise certains protocoles MPLS plutôt que l’IGP. Cisco documente des restrictions sur les routes rSPF apprises par IGP, BGP-LU et plusieurs topologies IGP. Ces limites n’étendent pas RFC 9107 et doivent être validées pour chaque famille déployée.

Les promesses produit ne remplacent pas la preuve. Une implémentation peut calculer correctement le best path de la racine configurée, alors que la racine représente mal le client, que la topologie est périmée ou que le candidat utile manque. Le bon fonctionnement du logiciel n’est qu’un maillon.

Les racines de secours rendent la perspective dynamique. RFC 9107 recommande de permettre des locations backup ; Junos expose notamment une racine primaire et une racine de secours. Si la première disparaît, l’observateur change. La reachability peut continuer tandis que de nombreux exits basculent.

Le backup doit avoir un route-set diff prévu et un test de forwarding. Sa simple présence ne prouve pas que son point de vue est acceptable. Il faut retirer la racine primaire sur un périmètre limité, observer le nouveau SPF, comparer les annonces et suivre la FIB.

Le forwarding hop-by-hop exige une prudence supplémentaire. RFC 9107 couvre aussi les réseaux tunnelisés, mais avertit que plusieurs reflectors sans encapsulation demandent une topologie soigneusement conçue pour éviter des boucles. Une décision rationnelle vue d’une racine peut s’articuler dangereusement avec la topologie réelle.

Le compute appartient au contrat. Chaque racine supplémentaire peut imposer un SPF et une partie du Decision Process sur une grande table. Une granularité fine peut retarder la convergence, saturer CPU ou mémoire et allonger les queues au moment même où l’IGP change rapidement.

Le capacity test combine nombre de routes, clients, racines, nœuds IGP et amplitude de panne. Il mesure état stable, recomputation complète, update incrémental et délai entre événement IGP, sélection ORR et annonce client. Une architecture correcte uniquement au repos n’est pas sûre en incident.

Le premier registre associe à chaque client et famille sa racine primaire, son backup, son groupe, sa policy, son propriétaire et l’approximation acceptée. Le second prouve les candidats, y compris le sens ADD-PATH entre reflectors. Le troisième enregistre l’époque topologique, les coûts calculés et le motif exact du path choisi.

Le quatrième registre appartient au client : route reçue, import, best-path reason, récursion, FIB et egress mesuré. Si le client choisit une autre route obtenue ailleurs, ce résultat est une réalité à expliquer, non une gêne à masquer.

Les scénarios doivent déplacer un client de groupe, supprimer la racine, activer le backup, cacher un candidat, vieillir la topologie, introduire un next hop récursif, appliquer une préférence supérieure et charger le compute. Chaque essai possède un delta attendu et une limite de temps.

Rollback restaure une perspective, pas seulement une ligne. Retirer ORR peut rendre au reflector son point de vue physique ; encore faut-il que les updates inverses atteignent les clients et modifient leur FIB. Si les candidats ont changé entre-temps, le baseline reste une preuve et non une machine à remonter le temps.

Les pouvoirs doivent être séparés. Les responsables IGP valident les racines, les responsables BGP approuvent groupes et politiques, les opérateurs du reflector gèrent capacité et rollout, et les propriétaires du trafic vérifient les exits. Un reviewer indépendant doit pouvoir contester la prétention selon laquelle une racine « représente » un client.

La spécification initiale minimale de Heng Lu correspond au mécanisme : un point logique et une étape de décision commune, sans imposer une architecture centrale ni une granularité universelle. Les décisions futures restent locales.

La primauté du code en fonctionnement ordonne les faits. Racine et groupe configurés sont des affirmations. Topologie apprise, candidats retenus, annonce spécifique, next hop programmé et paquets observés sont le système. Une configuration exacte alimentée par une vue incomplète reste opérationnellement fausse.

La souveraineté des données n’est pas la possession d’une base de topologie. Elle est la capacité pratique de comprendre, contester et vérifier la décision qu’elle produit. ORR corrige un défaut de centralisation par une centralisation mieux dirigée ; il faut donc gouverner la perspective logique comme une nouvelle autorité de routage.

Sources