Résumé

  • BGP PIC fait pointer de nombreux préfixes vers des objets de next hop hiérarchiques ; après une panne couverte, la modification de quelques objets partagés remplace une réécriture préfixe par préfixe.
  • La rapidité exige qu'un chemin de secours utilisable soit appris, sélectionné et installé avant l'incident. Une deuxième route ou un autre next hop BGP ne prouve ni la séparation des risques ni la capacité réelle du chemin.
  • La gouvernance doit suivre toute la chaîne : visibilité des candidats, éligibilité, destin commun, autorité du détecteur, hiérarchie matérielle, paquets observés et retour maîtrisé vers l'état stable.

À 2 h 14, un PE d'entrée perd sa sortie préférée. BGP n'a pas fini de recalculer les routes VPN et les route reflectors n'ont pas achevé leurs annonces. Pourtant, le trafic de plusieurs centaines de milliers de préfixes part déjà par un autre PE.

La salle d'exploitation s'émerveille de la convergence. Elle devrait d'abord demander qui a choisi ce chemin. La réponse n'est peut-être pas « le routeur pendant la panne », mais « le réseau plusieurs heures auparavant ».

Le routeur avait reçu une alternative, l'avait jugée admissible, avait résolu son next hop et l'avait associée à un objet de transfert partagé. Lorsque le détecteur a déclaré la dépendance primaire hors service, la forwarding plane a changé un petit nombre de pointeurs. Elle n'a pas reprogrammé chaque destination.

Voilà le sens précis de BGP Prefix Independent Convergence. L'expression ne signifie pas que toute convergence devient indépendante de la taille du réseau. Elle vise la durée d'une opération locale : après la détection d'une panne couverte, un transfert déjà préparé peut cesser de croître avec le nombre de préfixes concernés.

À la date de cet article, le texte IETF principal est draft-ietf-rtgwg-bgp-pic-23. C'est un Internet-Draft actif, destiné à devenir Informational. Il reste un travail en cours, pas un RFC et pas un nouveau protocole sur le fil. Il décrit une architecture interne de FIB hiérarchique, de résolution récursive et de chemins de secours précalculés.

Dans une FIB aplatie, chaque préfixe peut contenir une copie de tous les détails nécessaires au transfert. Si 500 000 routes dépendent du même egress, un changement peut imposer 500 000 mises à jour. Dans une FIB hiérarchique, ces feuilles partagent une pathlist BGP, puis un objet IGP résolu, puis une adjacency ou une pile de labels. Changer la branche commune suffit à faire hériter toutes les feuilles du nouveau parcours.

On ne réécrit plus l'adresse sur un demi-million de colis ; on déplace l'aiguillage commun du convoyeur. L'opération garde un coût matériel, mais il n'est plus répété pour chaque colis.

La limite est essentielle. La détection prend toujours du temps. Un reflector peut cacher le candidat. Le control plane doit toujours retirer, choisir et annoncer. Les autres routeurs convergent à leur rythme. Le chemin retour peut rester cassé et le secours peut manquer de capacité. « Prefix independent » retire le nombre de préfixes d'une étape locale, pas de toute la crise.

La précomputation est la contrepartie de la vitesse. Le routeur protecteur doit déjà posséder une alternative valide selon la policy, joignable, suffisamment distincte pour la panne visée et programmée dans la chaîne de transfert. La décision prise dans les premières millisecondes est donc une décision ancienne.

L'audit doit porter sur une intention dormante. Une route de secours peut rester inutilisée pendant des semaines. Lorsqu'elle devient active, le système suppose que le jugement ancien sur la topologie, la politique et les ressources reste valable.

La première preuve concerne l'arrivée des candidats. Le draft cite ADD-PATH, best-external, la distribution de chemins divers et, dans certains VPN, des Route Distinguishers distincts. Ce sont des moyens possibles d'alimenter le choix, pas des garanties équivalentes.

Route reflection peut supprimer l'alternative avant qu'elle n'atteigne le PE. Une capacité ADD-PATH affichée ne suffit pas non plus : le sens send/receive, l'AFI/SAFI, la policy de l'émetteur, le nombre de chemins, l'import et l'Adj-RIB-In effectif décident ce qui existe au point de bascule.

La deuxième preuve est l'éligibilité. La documentation Nokia SR Linux décrit, pour Edge PIC, un candidat valide, joignable et doté d'un next hop BGP différent de celui du primaire, puis choisi par le processus de décision BGP. Cette règle est cohérente, mais un autre next hop ne constitue pas un certificat de diversité.

Deux adresses peuvent se résoudre sur la même fibre, la même carte, le même tunnel, la même alimentation ou le même fournisseur. Deux PE peuvent dépendre du même service intermédiaire. La distinction logique n'empêche pas un destin physique commun.

Il faut donc annoncer le failure class couvert. Une autre interface peut protéger contre un port défectueux, pas contre la perte de la carte entière. Une deuxième route via le même PE ne protège pas contre la chute du PE. Deux sessions vers le même opérateur ne prouvent pas une indépendance commerciale ou géographique.

Core PIC et Edge PIC clarifient la couche attendue. Core PIC répare le parcours interne vers un next hop BGP qui reste joignable : l'IGP ou le transport change sous le même next hop. Edge PIC utilise un autre next hop BGP précompté lorsque l'egress disparaît, avec éventuellement un autre label VPN ou tunnel.

Ces termes ne garantissent pas un périmètre uniforme entre produits. Famille d'adresses, service, version logicielle, ASIC et carte de ligne comptent. Le draft rappelle d'ailleurs que le bénéfice provient de la conception de la forwarding plane, non d'une modification du protocole BGP.

Le détecteur détient la clé d'activation. État physique, interface, adjacence IGP, session BGP et BFD ne voient pas les mêmes pannes. RFC 5880 précise que le Detection Time BFD est calculé séparément dans chaque sens à partir d'intervalles négociés et d'un multiplicateur. Un simple label « 50 ms » cache cette asymétrie.

Des timers agressifs ont un coût. Congestion, famine du control plane, filtrage ou attaque peuvent faire disparaître des paquets BFD valides. RFC 5880 avertit qu'un faux down comme un faux up peut produire un déni de service. Accélérer le détecteur revient à autoriser un basculement massif sur la base de moins d'observations manquantes.

Le signal doit couvrir la bonne dépendance. L'état d'une interface détecte vite une coupure locale, mais pas un trou noir distant. BFD sur un lien atteste une adjacence, pas nécessairement le service au bout. Le chemin de la sonde et celui du trafic protégé doivent être comparés.

L'IGP peut lui-même masquer un défaut. La summarisation retire volontairement des détails entre zones. RFC 9929 définit l'Unreachable Prefix Announcement parce qu'un préfixe composant peut devenir inaccessible sans retrait du résumé qui le couvre ; le RFC cite notamment BGP PIC. Cela ne rend pas UPA obligatoire partout. Cela montre qu'une réparation ne peut agir sur une panne invisible à son point de décision.

La hiérarchie matérielle pose une autre frontière. Le draft suppose plusieurs niveaux d'indirection. Une plateforme plus limitée peut aplatir la chaîne lors de la programmation, dupliquer l'état et perdre une partie du partage. Elle consomme davantage de FIB et peut réintroduire un travail lié au nombre de préfixes.

Deux routeurs peuvent donc afficher les mêmes routes primaire et secondaire, mais basculer très différemment. L'un modifie un objet partagé ; l'autre réécrit une table aplatie. Une promesse de service doit être mesurée sur chaque combinaison de châssis, carte, version, famille et encapsulation.

Dans un L3VPN, le secours peut exiger un label VPN différent, puis une pile LDP ou Segment Routing différente. Un next hop correctement remplacé avec un label périmé donne une panne très rapide. La preuve doit suivre la chaîne jusqu'à l'adjacency et à l'encapsulation réellement émises.

L'état précalculé vieillit. Une modification d'import, un retrait, une nouvelle résolution, un changement de label ou une pression sur les ressources matérielles peuvent rendre le secours inadéquat. Le cas le plus dangereux n'est pas un backup absent, mais un backup toujours marqué prêt alors qu'il ne l'est plus.

Il faut enregistrer l'heure de réception du candidat, le dernier calcul d'éligibilité, la programmation FIB et l'époque de policy ou de topologie qui justifie le tout. Chaque changement pertinent doit relancer la validation de la chaîne dormante.

La capacité fait partie de l'autorisation. Un chemin peut être joignable et sans boucle tout en étant incapable d'absorber le trafic protégé. Si plusieurs primaires partagent le même secours, une seule panne peut y concentrer un agrégat immense. Les contrats de transit ou de peering peuvent aussi interdire un chemin que BGP juge techniquement valide.

RFC 5714 fournit le bon découpage temporel. Le fast reroute invoque une réparation locale après la détection, tandis que les protocoles distribués continuent à converger. La réparation est un pont, pas nécessairement l'état final.

Il faut mesurer six horloges séparées : détection, livraison de l'événement, activation FIB, premier paquet réussi, convergence du control plane et FIB stable final. Une valeur unique de « convergence » masque le responsable de chaque délai et ne dit pas si un paquet a été livré.

Les sondes data plane doivent observer l'interface, le next hop et la pile de labels avant, pendant et après la bascule. Le retour doit être testé indépendamment : firewalls stateful, NAT et chaînes de service peuvent perdre la session même si le sens aller change parfaitement.

La matrice d'essai doit inclure lien local, panne de transport distante, perte du PE, chute de session BGP, BFD retardé ou erroné, retrait préalable du secours, modification de policy, pression FIB, redémarrage de carte et retour du primaire. Pour chaque cas, nommer le détecteur, l'objet partagé, le chemin attendu, la perte admissible et l'état final.

Le faux positif envoie instantanément un vaste ensemble de préfixes vers un mauvais secours. Le faux négatif laisse une protection fictive : candidat non installé, trigger lié au mauvais objet ou entrée refusée par l'ASIC. L'état partagé sauve beaucoup de routes et multiplie aussi une erreur unique.

La sélection et la certification doivent donc être séparées. L'équipe routing définit les candidats ; le transport atteste les domaines de panne ; la plateforme prouve la hiérarchie matérielle ; le service valide capacité et bidirectionnalité ; un reviewer indépendant autorise l'extension.

Un registre de protection doit relier chaque failure class, route family, plateforme et service à son primaire, son backup, sa source, sa diversité, son détecteur, ses timers, son objet FIB, sa capacité et son owner. Un ledger d'état dormant doit distinguer le backup visible dans la RIB du backup réellement présent dans le matériel. Enfin, une trace horodatée doit relier le signal, le changement d'objet et les paquets.

Le retour au primaire mérite le même contrôle. Une bascule inverse immédiate peut provoquer réordonnancement, oscillation ou nouvelle perte. Hold-down, période d'observation ou revert approuvé peuvent être nécessaires. Rollback ne signifie pas désactiver PIC, mais retrouver un état stable prouvé.

Le principe de minimum initial specification de Heng Lu convient à cette architecture : garder le mécanisme commun étroit et laisser chaque opérateur choisir les familles, plateformes, pannes et seuils justifiés. Running-code primacy place ensuite le paquet au-dessus du bouton, de la RIB et même de la promesse FIB.

La souveraineté pratique exige enfin que l'opérateur puisse inspecter, tester, faire expirer et révoquer la décision stockée dans le matériel. Posséder le dépôt de configuration sans voir le secours dormant n'est qu'un contrôle symbolique.

BGP PIC déplace le travail hors de l'urgence. Pour rester gouvernable, il doit déplacer la preuve au même endroit. La voie de secours ne doit pas devenir visible pour la première fois lorsque le primaire disparaît. Son origine, sa diversité, son trigger, sa réalisation matérielle, sa capacité et sa date d'expiration doivent être connues avant l'alarme.

Sources