Résumé

  • La joignabilité du NEXT_HOP BGP reste nécessaire, mais les tunnels et services segment routing peuvent faire dépendre le transfert d’un autre objet, d’un autre contexte et d’une autre base de données.
  • Le tuple proposé impose que joignabilité, préférence, métrique et suivi proviennent d’une même résolution ; l’installation et la livraison doivent encore être démontrées séparément.

La même adresse peut cacher plusieurs chemins

Le modèle historique de RFC 4271 suppose qu’un locuteur BGP peut vérifier NEXT_HOP et déterminer le coût intérieur jusqu’à cette adresse. GRE, MPLS, SR Policy et SRv6 rendent cette hypothèse incomplète. Une adresse de contrôle peut rester joignable alors que le point de sortie d’un tunnel, la politique de segments ou le SID de service qui doit transporter les paquets ne l’est plus.

La révision 00 de BGP Best Path Selection Based on Next Hop Resolution a été publiée le 24 septembre 2026 par le groupe IDR. C’est un Internet-Draft destiné au Standards Track qui mettrait à jour RFC 4271 s’il était approuvé. Ce n’est encore ni une RFC, ni un consensus final, ni une mesure du déploiement réel.

Le texte introduit un objet de preuve précis : le tuple de résolution de chemin. Il associe une clé de résolution à un contexte facultatif. La clé peut être le NEXT_HOP ordinaire, le Tunnel Egress Endpoint de RFC 9012, ou un SID de service SRv6 de RFC 9252. Le contexte identifie ou paramètre la procédure et la source utilisées : attribut Tunnel Encapsulation, communauté étendue Color, ou informations de sous-TLV SRv6 autres que le SID lui-même.

Deux demandes portant sur la même clé ne sont donc pas forcément équivalentes. {N1, C1}, résolu par une SR Policy, et {N1}, soumis à la table ordinaire du prochain saut, décrivent deux observations. Supprimer le contexte revient à supprimer l’identité du chemin recherché.

Une résolution, un ensemble indivisible de faits

La règle déterminante du projet est simple : la joignabilité, la préférence, la métrique et l’état de suivi d’un chemin doivent désigner la même résolution. Il serait erroné de prendre une joignabilité obtenue dans un contexte A et une métrique plus favorable issue d’un contexte B. Le résultat peut sembler cohérent sur un tableau de bord, mais aucune composante du réseau n’a résolu ce chemin composite.

Les contraintes de résolution limitent les routes ou bases admissibles. Elles peuvent imposer un type de tunnel, interdire une agrégation ou ordonner des classes de transport. Elles régissent la manière de satisfaire le tuple sans devenir un troisième élément de celui-ci.

La vérification ordinaire de NEXT_HOP subsiste. Le projet ajoute une résolution du tuple, sous contraintes, que l’opérateur peut activer par configuration. Un objet de tunnel disponible ne permet donc pas d’ignorer un prochain saut classique devenu invalide.

La comparaison des métriques exige la même prudence. Une valeur peut représenter un coût IGP, une autre une latence, et une troisième résolution peut ne fournir aucun coût. Le projet propose une préférence de clé de résolution locale et numérique, où la valeur la plus faible est favorisée, pour classer d’abord les mécanismes hétérogènes. Après ce filtrage, le coût intérieur vient uniquement du tuple concerné. Si celui-ci est résolvable mais sans métrique, le coût maximal doit s’appliquer.

Huit reçus pour une décision vérifiable

Le reçu d’annonce conserve la route, NEXT_HOP et les attributs de tunnel ou de segment routing. Le reçu de tuple fixe la clé, le contexte et la règle de dérivation. Le reçu de contrainte nomme la politique locale et la base autorisée. Le reçu de résolution lie joignabilité, préférence, métrique, données de transfert et instant d’observation dans un seul résultat.

Le reçu de sélection expose les candidats, le filtrage par préférence, l’étape de coût comparable et le choix final. Le reçu de suivi identifie les abonnements au prochain saut et à chaque tuple distinct par son contexte, y compris pour les chemins non retenus. Le reçu d’installation constate le RIB, le FIB et l’encapsulation effectivement programmés. Le reçu de livraison observe enfin les paquets et le résultat du service.

Ces preuves ne sont pas interchangeables. Une route sélectionnée peut échouer à l’installation ; un tunnel programmé peut mener ailleurs ; un SID résolu ne garantit pas le service. Les risques de congestion, de perte ou de mauvais acheminement mentionnés par le projet sont des scénarios, pas des statistiques de production ni une démonstration de bénéfice.

Suivre aussi les chemins qui ne gagnent pas

Le réseau continue d’évoluer après la sélection. Le locuteur BGP devrait suivre à la fois le NEXT_HOP ordinaire et le tuple. La perte de l’un des deux, ou un changement de métrique du tuple, doit entraîner le réexamen de tous les préfixes concernés.

L’identité de l’abonnement doit inclure le contexte. Des clés identiques avec des contextes différents ne peuvent partager un même watcher. Les chemins non retenus doivent eux aussi rester suivis : ils peuvent devenir admissibles sans nouvelle annonce. Une déduplication de {N1, C1} avec {N1} détruirait précisément la frontière que le mécanisme veut rendre auditable.

Un socle commun, des préférences locales

Cette architecture rejoint le principe de Heng Lu d’une spécification initiale minimale et de décisions futures localisées. La norme commune peut définir l’identité du tuple et interdire le mélange de preuves sans imposer mondialement un transport préféré. Contraintes, valeurs de préférence et calendrier de déploiement restent des choix du domaine administratif.

La distinction entre autorité et croyance est également essentielle. Une annonce prouve ce qu’un locuteur a annoncé ; une résolution prouve ce qu’un système a trouvé. Aucune ne prouve que les paquets ont suivi l’intention. La primauté du code en fonctionnement exige alors versions logicielles, journaux atomiques, état programmé et observation du trafic.

Il faut enfin distinguer ce travail du mécanisme de classes de transport de RFC 9830. Color peut faire partie du contexte, mais la question ici n’est pas de valider l’import de couleurs ou une SLA. Elle est de savoir si tous les faits d’une décision BGP décrivent une même résolution.

Statut et limites

La révision 00 recommande une configuration cohérente entre locuteurs d’un même domaine. Cette cohérence réduit les divergences sans prouver l’alignement du plan de données. Le texte n’ajoute pas, selon lui, de considérations de sécurité au-delà de NEXT_HOP; de mauvaises contraintes, des bases obsolètes et des préférences incohérentes restent pourtant des risques d’exploitation.

Le projet peut changer et ses implémentations peuvent être absentes ou peu observables. Sa contribution immédiate est néanmoins claire : interdire qu’un système construise l’apparence d’un chemin unique avec des faits qui concernent plusieurs chemins.

Sources