Résumé

  • Le projet RIS présenté par le RIPE NCC en 1999 devait recueillir des annonces BGP à plusieurs endroits et les conserver pour étudier les changements de routage.
  • Le « tableau complet » était une ambition. Des collecteurs installés à quelques points documentaient les routes reçues, sans prouver la vue de tous les réseaux, le chemin des paquets ou l’accessibilité de bout en bout.

Une route absente : problème du réseau ou de l’observateur ?

Quand un service devient inaccessible, l’exploitant cherche une réponse concrète : la route a-t-elle disparu, ou ce réseau précis a-t-il cessé de la voir ? En octobre 1999, le RIPE NCC publie la conception du Routing Information Service, ou RIS, destiné à recueillir des informations de routage BGP à plusieurs endroits et à conserver leur évolution dans le temps.

Le document donne à cet historique un objectif pratique. Si un utilisateur signalait qu’un site avait été inaccessible plus tôt, les données de routage pouvaient aider à comprendre ce qui avait changé. Les opérateurs pourraient également examiner l’évolution des tables, la convergence et les oscillations de routes. Au lieu de dépendre uniquement d’une vue en direct après l’incident, ils pourraient comparer des états enregistrés à différents moments.

Mais l’ambition s’accompagnait d’une architecture plus limitée. Le RIPE-200 proposait d’installer des collecteurs de routes distants à quelques points majeurs et « topologiquement intéressants », par exemple dans de grands points d’échange. Ces machines devaient recueillir les annonces BGP puis transmettre les informations à un collecteur central et à une base de données. Le système devait réunir plusieurs points de vue ; il n’était pas placé partout dans le réseau.

Une donnée BGP appartient à une session

BGP est le protocole grâce auquel les réseaux échangent des informations d’accessibilité entre systèmes autonomes. Un collecteur participe à ces échanges de plan de contrôle afin de recevoir et de conserver les annonces de ses pairs. L’archive indique donc ce qui est arrivé à une session configurée, depuis un lieu et à un moment donnés.

Cette preuve est utile, mais son périmètre compte. Une route présente dans la table d’un pair ne démontre pas que tous les réseaux l’ont reçue. Son absence dans les données d’un collecteur ne prouve pas qu’elle a disparu partout. Une annonce ne montre pas non plus que des paquets ont emprunté le chemin annoncé, que la destination a répondu ou qu’un client a subi une panne. L’expression « tableau complet » du projet décrivait l’objectif visé par l’accumulation de données ; le document ne démontrait pas une couverture universelle.

Ce n’est pas un défaut propre au RIS. Les réseaux appliquent des politiques différentes et ne reçoivent pas tous la même vue des routes. Un système de mesure doit observer les échanges auxquels il participe. Ajouter des collecteurs élargit l’archive, mais chacun reste limité aux pairs et aux flux qu’il peut voir. L’emplacement de l’observateur fait partie de la preuve.

Un projet en cours, pas un service achevé

Le plan d’activité 2000 du RIPE NCC précise la chronologie. Il indique que le RIS figurait dans des plans depuis plusieurs années, mais avait peu progressé faute de temps et de ressources. La situation change en 1999 lorsqu’un ingénieur réseau rejoint le groupe des nouveaux projets pour travailler à plein temps sur ce sujet. Le plan situe le début des travaux en juillet 1999 et précise qu’un projet fut présenté à RIPE-33.

Le même document décrit les étapes alors attendues : une première version pour les utilisateurs bêta au début de 2000, puis un service régulier d’ici la fin de l’année. Les minutes de RIPE-35 indiquent que la proposition avait été présentée à RIPE-34, finalisée en octobre 1999 et publiée sous la référence RIPE-200 afin de recueillir des commentaires. Ces documents montrent une conception en voie de devenir un service ; ils ne mesurent pas les résultats d’un système déjà complet.

Cette distinction change la lecture historique. Le projet ne promettait pas seulement une nouvelle page de consultation en direct. Il cherchait à rendre l’historique du routage examinable et utile aux opérateurs. Pourtant, une base ne conserve que ce que ses collecteurs reçoivent et ce que le système garde. Les sources ne donnent ni le nombre de collecteurs au lancement, ni la date exacte de mise en service, ni la disponibilité, les utilisateurs ou les incidents que le service aurait ensuite aidé à résoudre.

Ce qu’un historique peut établir

L’apport durable de la conception de 1999 est une méthode : recueillir les annonces de routage depuis plusieurs points, les dater, les conserver et permettre aux opérateurs d’examiner leurs variations. Pour une enquête sur incident, cela offre un point de départ plus solide qu’un souvenir non daté ou qu’une seule table actuelle. Cela peut aider à distinguer un changement observé par un pair d’un changement visible dans plusieurs flux.

La méthode fixe aussi une limite. Une archive de routes n’est pas un recensement de toutes les décisions de transfert. Ce n’est ni une capture de paquets, ni une mesure de latence, ni un contrôle d’application, ni une preuve d’attribution d’une ressource Internet. Pour conclure à une accessibilité plus large, l’exploitant aurait besoin d’autres éléments, par exemple de mesures depuis la destination concernée. Il ne faut pas fondre ces observations distinctes dans l’archive du collecteur.

Le RIPE-200 est précieux parce qu’il montre simultanément la promesse d’un « tableau complet » et le choix d’observer depuis quelques points. Une bonne archive rend l’Internet plus observable sans le rendre entièrement visible. Sa valeur dépend de la connaissance du point de vue conservé, des flux qui l’alimentent et de ce qui reste hors champ.

Sources : RIPE-200, proposition initiale du RIS (13 octobre 1999) ; Plan d’activité 2000 du RIPE NCC, RIPE-197 ; minutes de RIPE-35 ; RFC 1771, BGP-4 ; documentation MRT du RIPE RIS.