Résumé

  • La RFC 1266 nommait trois implémentations BGP développées indépendamment et distinguait 56 routeurs dans sept systèmes du sous-ensemble opérationnel de 49 routeurs dans six systèmes.
  • Plus de 2 000 réseaux, des débits de 56 kbit/s à 45 Mbit/s et des matériels variés constituaient une preuve datée pour BGP-3, pas un recensement universel ni moderne.
  • Dans l’anneau CA*Net, le rapport reliait congestion, perte des paquets de routage et convergence lente, puis avertissait que cette configuration extrême ne devait pas devenir la norme d’interprétation.

Deux populations, et non un grand chiffre

La RFC 1266 répondait aux critères alors exigés pour faire progresser BGP vers le statut de Draft Standard. Elle ne se contentait pas d’affirmer que le protocole avait de l’expérience. Elle en donnait les coordonnées.

Trois lignées de code étaient présentes : celle de cisco sur son système de routeur, gated, code du domaine public fonctionnant notamment sur BSD et AIX, et l’implémentation NSFNET/IBM utilisée sur les dorsales T1 et T3. Le document les qualifiait de complètement indépendantes et interopérables. Cette indépendance teste mieux la précision d’une spécification que trois déploiements d’un même arbre source. Elle ne démontre toutefois ni l’absence d’erreur commune, ni l’exercice de tous les chemins d’échec.

Le détail des effectifs empêche l’arrondi narratif : 10 routeurs pour CA*Net, 20 pour la dorsale T1 NSFNET, 15 pour la dorsale T3, 7 pour le réseau d’essai T3, 2 pour CICNET, 1 pour MERIT et 1 pour PSC. Total : 56 routeurs, sept systèmes autonomes.

Le rapport retire ensuite le réseau d’essai du périmètre opérationnel. Restent 49 routeurs dans six systèmes autonomes. Dire « 56 routeurs opérationnels » ne simplifie pas la source ; cela efface sa réserve la plus vérifiable.

L’hétérogénéité était une partie de l’essai

Le nombre ne portait pas seul la démonstration. Les liaisons allaient de 56 kbit/s à 45 Mbit/s. Les machines s’étendaient du PC/RT au RS/6000. Des routeurs spécialisés côtoyaient des stations Unix. Les topologies allaient d’un anneau ou d’un arbre peu maillé à des dorsales denses. BGP transportait alors bien plus de 2 000 routes de réseaux extérieurs.

Chaque axe révèle une autre fragilité. Des codes d’origines différentes éprouvent les ambiguïtés du texte. Plusieurs systèmes d’exploitation éprouvent les hypothèses de mémoire et d’ordonnancement. Des débits éloignés éprouvent la perte et le délai. Des graphes différents éprouvent les chemins et les boucles.

La RFC 1164 montre le travail caché derrière le mot « implémentation ». TCP livre un flux, pas nécessairement un message BGP entier à chaque lecture. Le programme doit contrôler l’en-tête et la longueur, accumuler les octets manquants et ne pas bloquer le processus de routage. Une mise à jour est incrémentale : une route apprise demeure jusqu’à son retrait explicite ou son remplacement.

Dans la RFC 1267, BGP-3 envoie la table complète au début de la connexion, puis seulement les changements. Il n’existe pas de rafraîchissement intégral périodique chargé de corriger une divergence silencieuse. L’histoire de la connexion fait donc partie de l’état ; une rupture renvoie les pairs à Idle et oblige à reconstruire la vue.

Ainsi, « BGP fonctionne » agrège à tort plusieurs actes : cadrer le flux, conserver l’état, sélectionner une route, appliquer une politique, survivre à une perte et rebâtir une session.

Une attestation d’époque, pas un passeport perpétuel

La RFC 1266 indiquait une utilisation en production depuis 1989, les trois implémentations, toutes les fonctions importantes, des échanges entre transit et réseau terminal comme entre transits, et un environnement multiconstructeur. Elle rapportait aussi l’exercice de l’authentification et de la suppression des boucles.

Sa force vient des noms, des nombres et des conditions. Les présentations CA*Net et NSFNET du vingtième IETF étaient signalées comme support des mesures. En leur absence dans le paquet présent, il serait illégitime d’inventer des séries brutes, des marges d’erreur ou un taux de couverture.

De même, « plus de 2 000 réseaux » est une observation de charge pour 1991. Elle ne mesure ni une table BGP-4 ultérieure, ni les politiques modernes, ni la conformité actuelle d’un produit. Une preuve d’échelle possède une date et une grammaire de protocole.

CA*Net avait un enchaînement causal identifiable

Le cas le plus instructif était un anneau de dix routeurs CA*Net, reliés par des lignes de 56 kbit/s très chargées. La congestion faisait perdre une part importante des paquets transportant les informations BGP. Cette perte ralentissait ensuite la convergence.

L’ordre ne peut pas être inversé. Le rapport ne disait pas que TCP avait créé la congestion. Remplacer le transport n’aurait pas empêché les routeurs congestionnés de jeter des paquets. TCP pouvait retransmettre ce qui avait été perdu ; il ne possédait pas la politique de la file où la perte se produisait.

Deux surfaces d’action étaient distinguées. Réduire la congestion dépassait BGP. Réduire la part des paquets de contrôle abandonnés pouvait, en revanche, passer par une identification et une priorité : précédence IP, port TCP connu, ou adresses source et destination. CA*Net choisissait les adresses.

Modifier les temporisations de retransmission pouvait accélérer une nouvelle tentative, et réduire la fenêtre TCP pouvait limiter les données devenues obsolètes. La RFC refusait pourtant d’appeler cela une guérison. Réexpédier plus vite n’abolit pas la règle de file qui détruit le message.

Une priorité n’est pas davantage une preuve de résultat. Elle modifie l’admission du paquet de routage. Il faut encore observer la perte, le traitement des mises à jour, la sélection des routes, la convergence et le transfert effectif.

Le rapport enfermait lui-même son cas limite

CA*Net ne transportait pas les routes extérieures dans son protocole intérieur. BGP alimentait donc des calculs nécessaires au routage à l’intérieur de l’anneau, ce qui rendait son délai de convergence exceptionnellement sensible. La RFC 1266 qualifiait cette situation d’épreuve extrême et avertissait que ses résultats n’étaient pas la norme ; dans une configuration plus ordinaire, l’IGP véhiculerait les informations extérieures utiles au calcul interne.

Le cas n’est pas diminué par cette réserve. Il gagne une adresse. Une épreuve extrême peut révéler une dépendance avant les configurations ordinaires. Elle ne devient simplement ni le réseau médian, ni une défaillance universelle de TCP, ni une propriété intemporelle de BGP.

La RFC 1268 ajoute une autre limite : les chemins d’AS et la configuration locale servaient des politiques de réseaux terminaux, multiraccordés ou de transit. Une annonce de route ne constituait donc ni un titre d’autorité, ni une promesse de livraison. Le rapport observait la mécanique qui porte les décisions ; il ne validait pas toutes les décisions ni tous leurs effets.

Sources et limites d’inférence

Ces documents établissent la spécification, les conseils d’implémentation, les hypothèses d’usage, les trois codes, les populations déclarées, l’échelle de routes et l’observation CA*Net. Ils n’établissent pas les données complètes des actes de l’IETF, une adoption mondiale, le comportement de BGP moderne, la conformité présente d’un produit, la sécurité actuelle, une convergence universelle, la joignabilité, la livraison ou le résultat pour l’utilisateur.