Résumé

  • RFC 1222 permettait à deux entités logiques — l’une dans l’IGP du client, l’autre dans celui du backbone — de partager un équipement tout en échangeant leurs routes par EGP ou BGP.
  • Le client et l’organisation NSFNET restaient chacun responsables de l’intégrité de leurs informations de routage ; la jonction Ethernet conservait sa fonction de démarcation.
  • Deux démons actifs et une session locale réussie ne prouvaient ni l’isolement du noyau, ni l’installation correcte des routes, ni le transfert des paquets, ni la joignabilité.

La facture matérielle masquait une question d’autorité

RFC 1222, signé par H-W. Braun et Y. Rekhter en mai 1991, cherchait une interface moins coûteuse pour les abonnés du backbone NSFNET. Sa notice RFC Editor le classe comme document informatif ; sa fiche IETF Datatracker le conserve dans le flux Legacy. Ce n’était pas une norme Internet ni le compte rendu d’un déploiement déterminé.

Le premier NSFNET avait donné l’apparence d’un seul système de routage. Les routeurs Fuzzball du backbone utilisaient Hello, les réseaux intermédiaires employaient souvent RIP, et gated traduisait les métriques. Une variation née dans un campus pouvait traverser plusieurs administrations. Avec davantage de liaisons, cette circulation peu isolée favorisait les boucles et l’instabilité.

La phase T1 avait corrigé l’architecture en séparant fortement l’IGP du backbone de ceux des clients. RFC 1093 décrit cette interface ; RFC 1092 ajoute accords de représentation, base de politique et rejet des annonces non autorisées. L’échange extérieur limitait la contamination des métriques internes, mais ne prouvait ni l’autorisation de chaque route ni son effet sur le trafic.

Deux entités, une seule carcasse

L’isolation correcte imposait au client un pair de routage distinct, relié au nœud NSFNET et participant à son propre IGP. Pour les petits sites appelés à rejoindre le réseau T3, le routeur supplémentaire et sa maintenance devenaient une barrière.

RFC 1222 a donc séparé le besoin logique de sa réalisation physique. Une entité devait parler l’IGP du client ; une autre, l’IGP du backbone. Leur dialogue restait inter-domaines. Elles pouvaient néanmoins s’exécuter dans la même machine, deux démons échangeant EGP ou BGP par l’interface de bouclage ou par IPC.

La proximité ne changeait pas la nature du message. Le BGP de RFC 1163 transportait de la joignabilité entre systèmes autonomes. Une session sur lo0 restait un passage entre deux points de décision, même si aucun câble ne séparait les processus.

Le noyau partagé réintroduisait un lien caché

Le mémo avertissait que les deux démons ne devaient pas agir simultanément sur le noyau de manière indésirable. Le dessin logique ne garantissait donc pas deux tables indépendantes, deux ensembles d’interfaces ou deux destins de panne. Le noyau commun pouvait réunir ce que le protocole avait séparé.

Il faut lire les preuves par degrés. Un démon lancé prouve sa présence. Une session BGP établie prouve un échange de contrôle. Une route acceptée prouve une décision du démon. Seule une lecture du noyau prouve l’installation ; seule une observation du plan de données prouve le transfert ; seule une mesure au-delà du routeur renseigne sur la destination.

RFC 1222 demandait aussi des pare-feu forts entre IGP et un marquage extérieur lors de l’importation. Ce marquage conservait le contexte d’origine. Il ne garantissait ni l’authenticité de l’annonce, ni le maintien du tag, ni une décision correcte en aval.

La configuration suivait le domaine qu’elle décrivait

Le contrôle devait rester distribué. L’organisation du backbone et le fournisseur du réseau raccordé portaient chacun la responsabilité de l’intégrité de leurs propres informations. Le client régional pouvait fournir la configuration du démon tourné vers son IGP et garder la maîtrise des routes qui y entraient.

La liaison Ethernet demeurait la démarcation administrative et opérationnelle. Ainsi, une boîte commune ne rendait pas les journaux interchangeables. Le backbone pouvait attester ce qu’il avait annoncé ou reçu ; il ne pouvait pas certifier à lui seul la configuration interne du client. Une responsabilité écrite n’était pas davantage une preuve que l’intégrité avait été respectée.

À plus long terme, le mémo envisageait de déplacer la frontière vers le nuage C-NSS. Deux administrations auraient alors dû gérer le même support physique entre C-NSS et E-NSS. PPP et la gestion des lignes série pouvaient aider, mais la diversité du matériel compliquait l’attribution d’une panne. Une ligne active ne réglait pas la question de savoir qui contrôlait quel état.

La leçon de RFC 1222 tient donc en une discipline : réduire le nombre de machines sans réduire le nombre de faits. Processus, importation, noyau, interface, défaut physique, transfert et résultat restent des observations différentes.

Sources