Résumé

  • Achevée le 27 septembre, la revue précoce de Donald Eastlake pour le Routing Area Directorate conclut « Not ready ». Il s’agit de son appréciation d’un projet actif du groupe IDR, et non d’un refus de l’IESG.
  • La version 13 recommande de vérifier la joignabilité du prochain saut dans la base de transmission du plan de données choisi et permet un contrôle facultatif de disponibilité. Elle ne relie pas expressément l’échec de ces contrôles à l’exclusion de la route de la sélection.
  • La revue demande aussi de préciser l’état réellement utilisé : une entrée MPLS, un tunnel et une résolution récursive ne constituent pas des preuves équivalentes du chemin emprunté par les paquets.

Le mot « joignable » change de sens selon l’endroit où on le vérifie. Dans le cas imaginé par le projet, un routeur de bordure dispose d’une route IP vers un prochain saut, mais le trafic VPN doit passer par un chemin MPLS qui ne fonctionne pas. Le routeur pourrait continuer à choisir et annoncer ce chemin, alors qu’une autre issue existe. Ce dessin de réseau explique la motivation du texte ; il ne documente aucune panne identifiée chez un opérateur.

Le 27 septembre, le registre de l’IETF a marqué comme terminée la revue précoce de Donald E. Eastlake III, datée par son auteur du 25 septembre. Son résultat « Not ready » porte sur draft-ietf-idr-bgp-bestpath-selection-criteria-13. Le document demeure un Internet-Draft actif du groupe IDR, visant le statut de norme proposée ; sa situation auprès de l’IESG est « I-D Exists », sans date de réunion. La mention « Updates: 4271 (if approved) » signifie précisément que RFC 4271 n’a pas encore été modifiée. Le groupe avait déjà mené une dernière consultation et une revue par un directeur de domaine en 2020 : la nouveauté n’est donc pas la découverte du sujet, mais cette évaluation de 2026.

Le cœur de la version 13 comprend deux choix asymétriques. La joignabilité du prochain saut SHOULD être résolue dans la base de transmission propre au plan de données retenu. La disponibilité du chemin MAY être contrôlée par un mécanisme OAM de ce même plan. Le choix du plan, la politique et la technique du test restent hors du périmètre du projet. Eastlake ne conteste pas le problème ; il constate que le résultat négatif n’a pas de conséquence normative claire. RFC 4271 écarte déjà du calcul de phase 2 une route dite non résoluble. Or le projet ne dit pas sans ambiguïté qu’une route qui échoue au nouveau test acquiert ce statut. La formulation MUST que propose le relecteur appartient à ses commentaires, pas au texte actuellement soumis.

Autre difficulté : de quelle base de transmission parle-t-on ? Selon la politique et la topologie, un prochain saut MPLS peut être servi par une étiquette LDP, un préfixe Segment Routing, un tunnel RSVP-TE ou SR Policy, ou encore par une route BGP à étiquette résolue récursivement. Un voisin directement connecté peut n’utiliser aucune entrée étiquetée. Vérifier une entrée présente ailleurs dans le routeur ne démontre pas que celle qui portera le paquet est utilisable.

La revue propose de suivre le mécanisme et la récursion de la transmission effective, afin que deux implémentations confrontées aux mêmes données ne prennent pas des décisions divergentes pour une raison cachée.

Cette clarification doit aussi tenir compte de l’existant. RFC 9012 traite déjà comme non résoluble une route dont l’attribut Tunnel Encapsulation ne contient aucun tunnel réalisable. Eastlake demande ce qu’ajouterait le projet dans ce cas ; il ne démontre pas un conflit entre normes. Il attire enfin l’attention sur les effets possibles d’un test de vivacité : oscillations, faux signaux, état inconnu au démarrage, voire boucles si les routeurs IP ne prennent pas la même décision. Ces risques de conception ne sont pas des incidents mesurés.

Pour l’exploitation, la question utile n’est pas seulement « le prochain saut répond-il ? » Il faut savoir quel plan de données a été retenu, quel état précis a été consulté, et ce que le résultat a changé dans le choix du meilleur chemin. Relier ces trois faits est une recommandation d’analyse de Daniel Kade, non une obligation imposée par l’IETF. Ni la revue ni le projet ne mesurent la fréquence des pertes provoquées par ce défaut.

Sources