Résumé

  • Le paragraphe de statut du RFC 1105, daté de juin 1989, précise que des implémentations du Border Gateway Protocol existaient déjà pour les routeurs Cisco et les systèmes de commutation de NSFNET. Une version du domaine public destinée à gated était encore en cours de réalisation. Le document ne précise ni le nombre de systèmes concernés ni la portée de leurs échanges de routes.
  • En juin 1990, les RFC 1163 et 1164 présentent ensemble le BGP comme une norme proposée et indiquent expressément que l’expérience de déploiement pourrait encore le modifier avant son statut de norme Internet complète. Les implémentations apparaissent donc dans les archives avant cette étape de normalisation.

On résume souvent l’histoire ainsi : un organisme publie un protocole, les fournisseurs l’implémentent, puis les opérateurs l’adoptent. Le RFC 1105 décrit une chronologie moins linéaire. En juin 1989, son paragraphe de statut cite deux contextes d’implémentation, tandis qu’une troisième version, libre, pour gated est toujours en développement. Ce RFC n’est pas un recensement du déploiement : il ne donne ni versions, ni volumes de trafic, ni liste de sites, ni résultats de tests. Il constitue toutefois un témoignage contemporain direct : le BGP était implémenté au moment où sa première spécification était rédigée.

Le problème traité était le routage entre systèmes autonomes. Le RFC 1105 décrit un protocole permettant d’échanger des informations de joignabilité ainsi que les systèmes autonomes que le trafic devait traverser. Cette information sur le chemin pouvait aider à détecter les boucles et à appliquer des politiques à l’échelle d’un AS. Le document explique que la conception s’appuyait sur l’expérience acquise avec EGP et sur le backbone NSFNET. Le protocole n’a donc pas été conçu dans le vide : son texte s’est développé au contact de pratiques déjà en place.

Les mécanismes de cette première version montrent aussi combien la conception restait provisoire. Le message d’ouverture comportait un champ de type de liaison qui classait le pair comme interne, supérieur, inférieur ou horizontal dans une hiérarchie d’AS. Les mises à jour associaient des codes de direction aux numéros d’AS. Le protocole pouvait examiner la liste des AS pour détecter des boucles, tandis que la hiérarchie encodait une certaine représentation des relations entre réseaux. Ce sont les choix du premier RFC ; ils ne doivent pas être pris pour une description complète du BGP actuel.

En juin 1990, le RFC 1163 remplace le RFC 1105 et le RFC 1164 décrit l’application du protocole. Ensemble, ils définissent une norme proposée. Leur statut est révélateur : les auteurs écrivent que le protocole peut encore changer à la lumière du déploiement et encouragent les implémenteurs à partager leur expérience. Le RFC 1163 définit notamment l’attribut obligatoire AS_PATH, qui énumère les systèmes autonomes à traverser pour atteindre les réseaux annoncés. La représentation et la place du protocole dans le processus de normalisation ont donc évolué.

Ces textes ne prouvent pas qu’une implémentation Cisco ou NSFNET précise a causé une modification donnée. Ils ne relient pas chaque évolution aux commentaires d’un développeur. Ils établissent néanmoins une séquence : des implémentations existent en 1989 ; la spécification évolue en 1990 ; les textes de normalisation reconnaissent que l’expérience opérationnelle peut encore influer sur la suite. Le RFC 1266 étudiera plus tard l’exploitation du BGP, mais son rapport de 1991 relève d’un autre sujet, déjà traité séparément.

La Note 65 de Heng Lu, « Running-Code Primacy », propose une question éditoriale : qu’apportent des implémentations en fonctionnement qu’une proposition sur papier ne peut montrer ? C’est un angle de lecture, pas une source sur l’histoire du BGP ou de l’IETF. Les sources primaires permettent une réponse plus restreinte : en juin 1989, le travail d’implémentation est assez concret pour être mentionné ; en juin 1990, le texte continue de qualifier la conception de révisable. Ces documents n’établissent ni adoption universelle, ni fiabilité, ni succès commercial, ni continuité directe entre BGP-1 et le BGP moderne.

Ils montrent une étape de l’ingénierie Internet où code et spécification pouvaient évoluer ensemble.

Sources