Résumé

  • La révision 13 propose de résoudre le next hop dans la base de transfert du plan de données choisi par politique, et permet d'ajouter un contrôle de disponibilité OAM sur ce même plan.
  • La formule « une base de transfert » ne précise ni VRF, ni instance, ni table du tunnel ; deux systèmes peuvent donc juger différemment la même route.
  • Une décision exploitable doit conserver le plan, la table, le contexte de récursion, la version de politique, l'âge du contrôle et la raison exacte d'admission ou d'exclusion.

Le routeur possédait bien une route IP vers PE2. La session BGP était établie et le next hop se résolvait sans erreur dans le RIB. Pourtant, aucun paquet du client ne traversait le cœur MPLS : l'entrée de commutation d'étiquettes attendue avait disparu. Pour le plan de contrôle, PE2 restait joignable. Pour le plan qui devait réellement transporter le trafic, il n'existait plus.

La panne ne se trouvait pas dans la réponse « oui ». Elle se trouvait dans la question trop vague : joignable par quoi ?

draft-ietf-idr-bgp-bestpath-selection-criteria-13 cherche précisément à rendre cette question plus fine. La révision du 14 septembre 2026 est un Internet-Draft actif du groupe IDR, destiné au statut Proposed Standard et annoncé comme une mise à jour de RFC 4271 s'il est approuvé. Ce n'est pas un RFC. Les avis précoces actuels reconnaissent le problème, mais demandent encore des corrections ; le Datatracker signale qu'une nouvelle révision est nécessaire.

RFC 4271 exclut de la décision de phase 2 une route dont le next hop n'est pas résoluble. Cette règle devient insuffisante quand la récursion IP et le transfert effectif ne suivent pas le même plan. Dans le scénario MPLS VPN du projet, PE1 peut continuer d'annoncer une destination distante tant qu'il trouve PE2 dans ses tables IP, même si le LSP PE1–PE2 est inutilisable à cause d'une entrée MPLS absente, d'un lien d'étiquette défectueux ou d'une autre rupture interne. Le trafic est attiré, encapsulé puis perdu.

Le texte propose donc deux critères. Le premier indique que la joignabilité du next hop devrait être résolue dans une base de transfert du protocole de plan de données particulier. Si la politique choisit MPLS, il faut regarder la base MPLS ; si elle choisit IP, la base IP. Le second permet de vérifier la disponibilité fonctionnelle du chemin avec un mécanisme OAM associé au même plan.

Cette logique restaure une correspondance utile entre la décision BGP et le moyen de transport. Elle ne dit pas encore quelle réalité exacte consulter.

Une technologie ne désigne pas une table

Sur un équipement simple, « la table MPLS » peut sembler assez précis. Sur un PE multi-tenant, le préfixe client, l'adresse du next hop, l'extrémité du tunnel et la pile d'étiquettes n'appartiennent pas nécessairement au même espace. Une destination réside dans une VRF. Le tunnel se résout dans une instance d'infrastructure. Un SAFI transporte une information qu'un autre n'utilise pas. Une politique par voisin peut diverger d'une politique par famille.

L'avis Operations formule le problème : la révision 13 ne dit pas dans quelle table effectuer la résolution lorsque l'adresse de destination et l'extrémité du tunnel sont résolubles dans des tables différentes. La sélection du plan de données étant elle-même hors périmètre, l'opérateur ne reçoit pas de règle pour choisir l'instance qui fait foi.

Cette omission n'est pas une subtilité d'implémentation. Si deux routeurs consultent deux tables différentes, ils construisent deux ensembles de candidats. L'un conserve la route, l'autre l'exclut. Chacun peut ensuite propager son résultat par BGP. La décision locale devient une différence visible au-delà de l'équipement.

Une preuve exploitable doit donc nommer davantage que MPLS. Elle doit lier le résultat au préfixe, au chemin BGP, au voisin, à l'AFI/SAFI, à la VRF, à l'instance de routage, à l'adresse récursive, à la table de transfert, à la génération de cette table et à la version de politique qui l'a choisie. Sans cet identifiant composé, un journal disant « next hop absent » ne permet ni reproduction ni contestation.

Le contexte normatif a lui aussi changé. Le projet cite encore RFC 5512 pour l'encapsulation, alors que RFC 9012 l'a remplacé et modifie déjà certains aspects de la résolubilité. Les avis mentionnent également SR Policy et les travaux ultérieurs de résolution colorée. L'ordre de priorité entre ces mécanismes doit être explicite : lorsqu'ils pointent vers des plans différents, la première question opérationnelle est de savoir lequel commande.

La vérification fonctionnelle ajoute une autre autorité

Le deuxième critère autorise un contrôle de disponibilité du chemin par un mécanisme OAM du plan choisi. Le texte n'impose ni BFD ni LSP Ping ; ces mécanismes apparaissent dans les analyses des reviewers et les RFC connexes. Il laisse la méthode, son déclenchement et la politique hors périmètre. Le contrôle peut être lancé à la demande ou exister à l'avance.

Cette flexibilité a un prix. Un résultat préalable peut être périmé lorsque BGP le consomme. Un test à la demande peut ralentir ou charger la décision. Une absence de session au démarrage peut signifier « non initialisée » plutôt que « chemin en panne ». Une réponse positive peut concerner une FEC ou un membre ECMP tandis qu'un autre reste cassé. Une réponse négative peut provenir du mécanisme de mesure alors que les paquets de production passent encore.

Les avis Security et Operations décrivent le cas inverse du problème initial. Si un faux négatif exclut un chemin sain, BGP peut retirer une bonne route et créer la coupure que le contrôle devait empêcher. Un acteur capable de perturber les paquets OAM peut transformer ce pouvoir en déni de service ou en outil d'aiguillage vers un autre PE. Une fausse réponse positive conserve au contraire le chemin défectueux.

La classification doit donc distinguer positif, négatif et indéterminé. L'indéterminé n'est pas une faiblesse de tableau de bord ; c'est l'état exact d'une mesure expirée, non initialisée, contradictoire ou indisponible. Décider ensuite de conserver, de dégrader ou d'exclure la route relève d'une politique locale qui doit être visible et versionnée.

Un next hop vivant n'est pas un service livré

Même correcte, la preuve reste bornée. Une entrée de transfert confirme un état local. Une réponse OAM confirme que le mécanisme défini a réussi dans son périmètre. Elle ne démontre pas que tous les membres d'un ensemble de chemins fonctionnent, que la recherche dans la VRF distante aboutit, que le préfixe client est installé, que l'application accepte la requête ou que l'objectif de service est respecté.

Il faut conserver la chaîne : chemin reçu ; plan et table choisis ; état de transfert observé ; méthode OAM et horodatage ; interprétation de politique ; nouvelle sélection BGP ; installation locale ; annonce ou retrait ; traitement par les pairs ; mesure indépendante du trafic ; résultat applicatif. Le passage d'une étape à la suivante doit produire son propre reçu.

Cette séparation évite deux erreurs symétriques. « Le contrôle OAM est vert » ne signifie pas « le service fonctionne ». « La route a été retirée » ne signifie pas « le chemin était cassé ». Dans les deux cas, le système décrit une action ou une observation locale et non l'issue complète.

Rendre le choix contestable

L'avis Operations souligne que le résultat du contrôle n'est pas observable dans le projet actuel. Un opérateur voyant une route non retenue ne sait pas nécessairement que ce critère l'a disqualifiée. Il manque le plan choisi, le résultat par next hop et le nombre de chemins concernés. Sans ces éléments, le dépannage commence par deviner la règle cachée.

Une mise en service prudente devrait d'abord calculer le nouveau verdict en mode témoin. Pendant cette phase, aucune route n'est exclue. L'équipe compare le verdict à des compteurs de transfert, des sondes indépendantes et des mesures applicatives. Elle mesure les faux négatifs, la fraîcheur, les oscillations et la taille du groupe de routes qui partage chaque next hop.

L'activation vient seulement après la définition d'une durée de validité, d'un comportement au démarrage, d'une temporisation, d'un seuil de retour et d'un mécanisme de dérogation. Le retour arrière doit restaurer une politique connue et relancer explicitement la sélection des routes affectées. Arrêter une sonde sans purger son ancien verdict n'est pas un rollback.

La contribution essentielle de la révision 13 est de rappeler qu'une route IP ne prouve pas l'existence du plan MPLS qui portera les paquets. La discipline suivante consiste à ne pas remplacer cette simplification par une autre. Une table, une sonde ou un état de protocole ne doit pas devenir, à lui seul, vérité sur le service. L'autorité doit rester attachée à un contexte nommé, à une preuve datée et à une décision réversible.

Sources