Résumé

  • Le dossier présenté par InterLAN IX à RIPE 93 décrit Lighthouse en service sur neuf routeurs Nokia, vingt commutateurs Arista, 197 services et un portail comptant 214 clients. Chaque changement peut recevoir un aperçu par équipement, une validation, un contrôle d’accessibilité et un minuteur de retour arrière.
  • L’API externe peut demander une écriture au travers d’une transaction ; l’assistant d’IA n’accède qu’aux outils de diagnostic en lecture seule. Les changements proposés par l’IA figurent parmi les projets, avec examen et approbation humains.

Une interface peut annoncer « terminé » alors que deux routeurs racontent deux histoires différentes. C’est à cet endroit précis que se joue l’automatisation d’un point d’échange. Dans le programme Connect de RIPE 93, Andrei Dinu présente Lighthouse, l’outil d’InterLAN IX qui prépare des modifications de réseau pour plusieurs appareils. Ses diapositives originales parlent de transactions « atomiques ». Elles montrent surtout le travail caché sous cette formule : configuration prévisualisée appareil par appareil, validation avant engagement, contrôle de l’accès au routeur, confirmation et journal de l’exécution.

Le parc annoncé donne sa taille au problème. InterLAN déclare neuf routeurs Nokia, vingt commutateurs Arista, 197 services et 214 clients du portail. Il s’agit de chiffres présentés par l’exploitant, pas d’un décompte publié des transactions réussies. Le portail permet au client de voir ses services et d’en demander d’autres dans des limites définies. Une demande apparemment simple peut toutefois toucher plusieurs équipements, parfois de fabricants différents. Une erreur de balise VLAN ou de filtre n’a pas besoin d’un grand nom pour provoquer une grande soirée.

La page consacrée aux routeurs Nokia décrit un minuteur de confirmation. Si la configuration n’est pas confirmée, l’appareil revient en arrière. Lighthouse vérifie l’accessibilité et conserve le résultat dans le journal. La capture d’écran affiche quatre minutes et quarante-deux secondes restantes : c’est l’état d’un exemple, pas la durée générale du dispositif. L’intérêt du minuteur est ailleurs. Quand le chemin de gestion se casse après une écriture, la machine doit pouvoir retrouver une configuration utile sans attendre que l’opérateur parvienne à la rejoindre.

InterLAN montre aussi la querelle qui survit à tous les minuteurs : qui détient la bonne version du réseau ? Lighthouse compare la configuration enregistrée et celle que porte réellement l’appareil. Les modifications faites à la main apparaissent comme des écarts. Des contrôles signalent notamment des SAP absents et des identifiants ou EVI dupliqués. Un opérateur peut réparer au moyen d’une transaction ou adopter un changement manuel lorsque les règles l’autorisent. Le registre de l’état voulu a donc du pouvoir ; il ne doit pas effacer, sous prétexte de propreté, une réparation d’urgence effectuée sur le routeur.

Le laboratoire numérique sert à répéter une opération avant sa sortie en production. Il part de la dernière configuration sauvegardée, reconstruit la topologie avec Containerlab et Nokia srsim, puis exécute presque la même configuration. Les diapositives précisent que le laboratoire possède ses propres appareils et données, sans retour d’écriture vers la production. Elles indiquent aussi ses limites : les équipements doivent déjà être préparés, et la simulation Arista vEOS ainsi que celle des clients BIRD restent prévues. Une répétition utile garde la trace de ce qu’elle ne reproduit pas encore.

L’IA arrive plus tard dans la chaîne de commandement. L’API externe accepte des lectures et des écritures, mais les écritures passent par verrous, transactions, retour arrière et audit. L’assistant d’IA, lui, dispose d’outils MCP en lecture seule pour consulter état, journaux et diagnostics. Les exemples affichés concernent un rapport client et un plan de migration. La dernière diapositive réserve les changements assistés par IA à un chantier futur : proposer, examiner, approuver. La machine peut préparer le dossier ; elle ne signe pas l’ordre de manœuvre.

InterLAN héberge aussi à Bucarest RRC22, un collecteur du service RIS de RIPE NCC. RIPE NCC tient ce service de mesure, tandis qu’InterLAN exploite le point d’échange et Lighthouse. Un collecteur observe les routes ; une base de données décrit l’état souhaité ; un routeur exécute l’état courant. Confondre ces trois registres rendrait le beau portail beaucoup moins instructif.

Il manque un chiffre pour juger la promesse de sûreté : un relevé daté des transactions tentées, des engagements partiels et des retours arrière effectivement réussis. Les diapositives donnent l’architecture et une photographie du parc, sans série de résultats. Cette limite rend la décision plus nette. Avant d’ouvrir davantage la porte aux demandes automatisées, InterLAN doit pouvoir montrer, appareil par appareil, qui a demandé quoi, ce qui a été écrit et ce qui a survécu au minuteur.

Sources : séance Connect de RIPE 93 ; diapositives originales Lighthouse ; liste des collecteurs RIS de RIPE NCC.