Le CIDR a sauvé la table de routage mais a élargi l'administrateur

Résumé

• Les mesures reconstituées à partir des observations de Merit dans le contexte de NSFNET et des données horaires de SURFnet montrent un allégement substantiel du routage en 1994–1995, mais la série change de point d'observation, manque d'un dénominateur à l'échelle d'Internet et ne divulgue pas séparément son traitement des routes plus spécifiques.
• La chaîne de déploiement est passée des changements d'allocation topologique en 1992–1993 au plan NSFNET de juin 1993, aux spécifications CIDR de septembre 1993, aux tests des fournisseurs en 1993, à la norme BGP-4 de juillet 1994, au déploiement par les fournisseurs et à l'inflexion observée en 1994–1995.
• Le CIDR a créé des points de décision importants pour l'IANA, l'Internet Registry, le RIPE NCC, Merit, les fournisseurs, les concepteurs, les opérateurs et les systèmes autonomes voisins, tandis que les documents conservés établissent une capacité structurelle plus solide qu'un effet de levier exercé à l'échelle de la population.
• La conclusion limitée est que le CIDR a produit des gains de routage importants, spécifiques au point d'observation, cohérents avec l'agrégation; AlterNet fournit le seul exemple de fournisseur quantifié après déploiement dans les documents accessibles, tandis qu'un deuxième cas mis en œuvre et un résultat client nommé restent absents.

Le problème d'ingénierie était déjà mesurable avant que les conséquences institutionnelles ne soient claires.RFC 1519, publiée en septembre 1993, reproduisait une série fournie par Merit contenant 173 routes annoncées en juillet 1988 et 8 561 en décembre 1992. Les observations provenaient du contexte de routage de NSFNET. Leur unité était une route annoncée enregistrée dans cette série opérationnelle, plutôt qu'une allocation d'adresse, une organisation connectée, un système autonome ou un décompte universel de chaque route visible partout. RFC 1519 identifie Merit comme source mais ne nomme pas le collecteur individuel, ne documente pas un appareil de collecte inchangé sur toute la période, ni ne précise comment les routes plus spécifiques étaient traitées. Aucun dénominateur significatif à l'échelle d'Internet n'accompagne la série.

Dans ces limites, la hausse a été sévère: le nombre de décembre 1992 était environ 49,5 fois celui de juillet 1988 sur 53 mois. L'analyse de RFC 1519 elle-même traitait le segment 1988–1991 comme doublant en moyenne tous les dix mois. Ce taux appartient à cet intervalle historique défini et à cet ensemble de données du contexte NSFNET. Il ne doit pas être reporté comme si un seul moniteur mesurait en continu la même population Internet au même rythme jusqu'au milieu de la décennie.

La première preuve post-déploiement est très différente. L'étude du praticien Geoff Huston de mars 2001,« Analyzing the Internet's BGP Routing Table », a relié les observations mensuelles antérieures de Merit aux mesures horaires commencées par Erik-Jan Bos à SURFnet aux Pays-Bas au début de 1994. Huston a ajouté un troisième point de mesure à la périphérie de l'AS 1221 en Australie à partir de 1997, bien que ce point d'observation ultérieur soit en dehors du verdict quantitatif ici. La partie de 1994 est donc une vue horaire de SURFnet d'une table BGP sans défaut intégrée dans une reconstruction dont le segment antérieur provenait de Merit. Il ne s'agit pas d'un instrument, d'un collecteur ou d'un emplacement unique fonctionnant sans changement depuis 1988.

Huston a rapporté que la table visible est restée relativement constante à environ 20 000 entrées en 1994. L'unité était une entrée de table BGP visible au point de mesure SURFnet; la base de référence était la montée d'apparence exponentielle qui s'est poursuivie jusqu'au début de 1994. La source attribue le plateau aux ajouts de blocs fournisseurs nouvellement annoncés compensés par la suppression des annonces de composants par l'agrégation. Elle ne rapporte pas séparément comment la série historique comptait les routes plus spécifiques à ce moment-là, de sorte que le total approximatif ne peut pas être décomposé en agrégats, exceptions clients, annonces de multihébergement ou autres spécificités à partir du seul article.

Cette limitation change l'échelle de l'affirmation, pas sa direction. Une série pré-CIDR influente est passée de centaines à des milliers de routes annoncées. Une reconstruction ultérieure montre une vue sans défaut approchant environ 20 000 entrées, puis se maintenant près de ce niveau pendant une grande partie de 1994 alors que le réseau continuait de s'étendre. L'observation est cohérente avec le mécanisme exact que CIDR et BGP-4 étaient destinés à permettre: remplacer plusieurs annonces topologiquement alignées par un préfixe agrégé plus court.

Le résultat a été un allégement d'ingénierie substantiel. C'était aussi un allégement limité. Le dossier ne fournit pas de recensement simultané de tous les routeurs sans défaut, une définition commune couvrant tous les ensembles de données, ou un compte rendu route par route des annonces qui ont disparu. La conclusion quantitative la plus forte est confinée aux observations de 1994–1995: la croissance du routage aux points d'observation cités s'est nettement écartée de sa trajectoire antérieure pendant la période où les fournisseurs ont déployé le routage sans classe et l'agrégation.

Avant que la mesure ne devienne mythologie

Les prévisions de crise exigent la même rigueur de source que les décomptes observés. RFC 1519 indiquait qu'une table sans défaut contenait environ 4 700 entrées en janvier 1992, en citant les routeurs de backbone NSFNET comme exemple et en décrivant ce nombre comme la taille de la base de données de routage NSFNET. Son tableau mensuel détaillé répertorie 4 526 routes annoncées pour janvier et 4 740 pour février. Le chiffre textuel approximatif n'est pas une autre observation exacte et doit rester distinct des deux lignes mensuelles.

En utilisant le doublement moyen sur dix mois constaté pour 1988–1991, RFC 1519 prévoyait environ 30 000 entrées dans les deux ans. Elle modélisait séparément la pression supplémentaire qui pourrait survenir si les organisations incapables de recevoir un réseau de classe B obtenaient et annonçaient à la place plusieurs réseaux de classe C. Dans cette hypothèse, le document prévoyait plus de 10 000 entrées dans les six mois et 20 000 en un an. Il s'agissait de résultats de modèles prospectifs basés sur un point de départ de janvier 1992 et supposant la poursuite de la croissance antérieure. Ce n'étaient pas des mesures ultérieures.

Les scénarios à trois ans étaient plus ambitieux. RFC 1519 calculait environ 75 000 routes sans action corrective, 5 650 avec une mise en œuvre immédiate et une participation complète, et 13 145 avec une participation des fournisseurs de 90 %. Le résultat de 5 650 supposait, entre autres, que les blocs fournisseurs initiaux couvriraient deux ans de demande, qu'il y avait environ 100 fournisseurs, que moins de 100 organisations multihébergées existaient au départ, et que le multihébergement augmenterait à un rythme donné. Le scénario de 13 145 ajoutait une part modélisée de non-entités. Chaque résultat exprimait ce que les hypothèses des auteurs produisaient; aucun n'était une observation future attendant d'être confirmée.

Les valeurs observées aux points d'observation cités en 1994 et octobre 1995 étaient bien inférieures à la projection de 75 000 routes sans action. Cette comparaison conforte le succès pratique de l'agrégation sans prétendre que le contrefactuel non observé ait été prouvé. Les mises à niveau des routeurs, l'évolution de la demande, les valeurs par défaut, les choix de politique, la restructuration du réseau et d'autres développements contemporains ont également influencé ce qu'une table particulière contenait. L'argument causal du CIDR repose sur le moment de l'inflexion, le mécanisme de déploiement documenté et les preuves directes que les fournisseurs ont remplacé plusieurs routes internes par moins d'annonces externes.

Un deuxième taux est apparu dansRFC 1467, publiée en août 1993. La base de données de routage politique NSFNET/ANSNET de Merit augmentait alors d'environ 8 % par mois, ce que le document décrivait comme un doublement sur neuf à dix mois. Il s'agissait d'un taux actuel pour les entrées de cette base de données politique, et non d'une extension de l'analyse de RFC 1519 pour 1988–1991. La base de données était limitée par les politiques d'utilisation acceptable de NSF et ANSNET et n'était pas identique à une table de transfert complète.

RFC 1467 signalait plus de 13 000 réseaux dans cette base de données, dont plus de 10 000 étaient actifs fin juin 1993. Ici, la première unité est une entrée de réseau de la base de données; la seconde est un réseau annoncé au backbone NSFNET/ANSNET. Merit publiait périodiquement ces données, mais la RFC ne fournit pas de spécification complète du collecteur ni de compte rendu basé sur les masques des routes plus spécifiques. Elle estimait également que les réseaux connus d'autres fournisseurs mais absents de la base de données des politiques d'utilisation acceptable représentaient moins de 25 % de la population de la base de données, tout en reconnaissant que leur taux de croissance n'avait pas été mesuré. Ces chiffres décrivent un ensemble de données opérationnelles important limité par les politiques, et non l'ensemble du système BGP.

Une troisième déclaration sur dix mois provient de la rétrospective rédigée par les entités de Merit,NSFNET: A Partnership for High-Speed Networking, Final Report 1987–1995. Le rapport accessible ne fournit pas de date de publication explicite. Il indique que les tables de routage NSFNET doublaient environ tous les dix mois et enregistre le déploiement du CIDR sur le service backbone NSFNET en 1994. Il fournit la mémoire institutionnelle de personnes impliquées dans le programme. Son statut est celui d'un témoignage rétrospectif non daté, distinct de la série datée de RFC 1519 et du taux de la base de données politique actuelle de RFC 1467.

Les trois déclarations de doublement convergent vers une urgence de mise à l'échelle mais ne peuvent pas être fusionnées en une seule mesure continue. RFC 1519 analysait les observations de 1988–1991 d'une série Merit dans le contexte NSFNET. RFC 1467 décrivait la croissance en 1993 de la base de données politique NSFNET/ANSNET. Le rapport final de Merit résumait plus tard l'expérience du programme. Leurs définitions, fenêtres et statuts de preuve diffèrent.

La chaîne de déploiement, dans l'ordre

Le CIDR n'est pas arrivé sous la forme d'une simple publication de normes suivie d'une chute instantanée du nombre de routes. La gestion des adresses a évolué avant que les mécanismes de routage ne soient généralement prêts, et ce séquençage a initialement risqué d'augmenter la table.

La chronologie commence en 1992. RFC 1467 rapporte qu'au 31 octobre 1992, l'IANA avait mis en place des critères pour reconnaître les registres d'adresses régionaux et accepté les demandes des registres potentiels. Le RIPE NCC a reçu 194.0.0.0 à 195.255.255.255 pour l'administration en Europe et détenait déjà 193.0.0.0 à 193.255.255.255. Les allocations de classe B sont devenues progressivement plus difficiles à obtenir, tandis que des blocs de numéros de classe C de taille appropriée étaient privilégiés lorsque cela était possible. Dans les régions sans registre régional désigné, l'Internet Registry poursuivait la fonction d'allocation.

Au 15 avril 1993, l'Internet Registry allouait conformément au plan d'adressage topologique en blocs de numéros de classe C, et les fournisseurs demandaient des blocs pour les attribuer à leurs clients. Le RIPE NCC ou l'Internet Registry, agissant pour les régions concernées, fournissaient ces blocs fournisseurs. Il s'agissait de changements vérifiés dans la pratique d'allocation. Ils créaient des plages contiguës capables d'agrégation ultérieure; ils ne compressaient pas eux-mêmes une table de routage.

Un jalon prévu pour la disponibilité générale de l'agrégation d'adresses le 6 juin 1993 a été manqué. RFC 1467 attribue le retard à l'état des logiciels de routage. Son enquête décrit des implémentations en test interne, en planification pré-bêta ou bêta, des intentions de version limitée, des fonctions d'agrégation ou de désagrégation manquantes, et des routeurs qui nécessitaient encore des logiciels compatibles. Les dates indiquées étaient des plans et des prévisions faits en 1993, et non la preuve d'un achèvement ultérieur en production.

RFC 1482, publiée en juin 1993, présentait l'intention de Merit de prendre en charge l'agrégation dans la base de données de routage politique NSFNET et proposait un registre d'agrégation CIDR. Elle décrivait l'été 1993 comme la période prévue pour activer BGP-4 et l'agrégation CIDR, tout en attribuant à chaque entité la responsabilité de sa part de mise en œuvre. Le document est révélateur sur le plan opérationnel car il identifie les bases de données, les rapports, les processus de configuration, les champs d'enregistrement et les problèmes de coordination qui devaient changer. Il demeure un plan plutôt qu'un compte rendu après action.

RFC 1518et RFC 1519 ont été publiées en septembre 1993. RFC 1518 fournissait l'architecture pour aligner l'allocation d'adresses sur la topologie de routage et examinait l'équilibre entre abstraction et administration décentralisée. RFC 1519 fournissait la stratégie d'attribution d'adresses et d'agrégation sur la voie des normes, y compris le transfert par préfixe le plus long, le traitement des trous et du multihébergement, les hypothèses d'allocation et les responsabilités d'agrégation. Les documents décrivaient l'architecture et la sémantique de routage indépendante du protocole. La publication ne certifiait pas que les fournisseurs avaient déployé les logiciels nécessaires.

En 1993, les fournisseurs et les concepteurs testaient ou planifiaient le code BGP-4. RFC 1467 enregistre des états différents chez 3Com, ANS, BBN, Cisco, Proteon et Wellfleet. Certains codes pouvaient recevoir des routes sans classe mais ne pouvaient pas former d'agrégats; certains manquaient de désagrégation contrôlée; certains restaient en test interne; certains dépendaient de la mise à niveau d'anciens routeurs vers GateD. Les limites matérielles et de configuration des fournisseurs variaient également. Il s'agissait d'un domaine de capacités partielles, et non d'une version synchronisée.

BGP-4 a atteint la publication sur la voie des normes en tant queRFC 1654en juillet 1994. Il codifiait la joignabilité sous la forme d'un préfixe avec une longueur explicite et spécifiait les comportements de sélection de route, de diffusion, de réduction d'informations et d'agrégation. Le CIDR était la stratégie d'allocation et d'agrégation; BGP-4 était le protocole inter-domaine qui transportait la joignabilité sans classe. L'allocation topologique pouvait commencer sans que le déploiement de BGP-4 ne soit terminé, mais la réduction promise des routes dépendait de l'installation et de l'utilisation des protocoles sans classe.

Le rapport final de Merit situe le déploiement du CIDR sur le backbone NSFNET en 1994. Huston décrit un effort concerté de déploiement des fournisseurs en 1994 et 1995. Sa série reconstituée montre l'inflexion résultante au point d'observation de SURFnet.RFC 4632, publiée bien plus tard en août 2006, décrit de manière similaire une forte baisse en 1994 lorsque le déploiement de BGP-4 par les fournisseurs a permis d'agréger les blocs nouvellement alloués, suivie d'une croissance à peu près linéaire à partir du milieu de 1994.

Cette chronologie concilieRFC 2008, publiée en octobre 1996, avec le dossier de déploiement contemporain. RFC 2008 indique de manière générale que le CIDR était déployé depuis fin 1992. Cette date peut englober l'allocation topologique précoce et le programme de transition initial. Elle ne peut raisonnablement pas signifier qu'un déploiement complet de l'agrégation BGP-4 sur la voie des normes existait chez les fournisseurs fin 1992. Le jalon manqué de juin 1993, les rapports d'état des fournisseurs, la spécification BGP-4 de juillet 1994 et le dossier de déploiement de 1994–1995 établissent les couches qui ont suivi.

La séquence allocation-d'abord explique l'accélération temporaire identifiée rétrospectivement dans RFC 4632. Les registres émettaient des blocs destinés à l'agrégation alors que les fournisseurs annonçaient encore leurs réseaux de composants de classe C via des accords de routage hérités ou incomplets. Jusqu'à ce que les fournisseurs puissent créer et échanger des agrégats sans classe, un bloc destiné à devenir une route pouvait apparaître sous la forme de nombreuses routes. Le déploiement a comblé cet écart.

Huston et RFC 4632 associent également les plus grands mouvements à la baisse aux périodes suivant les réunions du groupe de travail sur le déploiement du CIDR de l'IETF. Il s'agit d'une interprétation rétrospective de la correspondance temporelle, et non d'une démonstration contrôlée qu'une réunion particulière a causé un nombre spécifié de retraits. Les réunions faisaient partie de l'environnement de coordination. Le résultat mesuré est survenu grâce à l'installation de logiciels par les fournisseurs, à la configuration des agrégats, aux modifications des annonces et à l'acceptation par les systèmes voisins.

Ce qu'un agrégat nécessitait

La compression technique était conceptuellement simple. Une route sans classe indiquait un préfixe d'adresse et sa longueur. Plusieurs réseaux contigus suivant le même chemin externe pouvaient donc être représentés par un préfixe commun plus court. Le transfert par préfixe le plus long conservait un mécanisme d'échappement: une route plus spécifique à l'intérieur de l'agrégat pouvait diriger le trafic différemment pour le multihébergement, une transition de fournisseur ou une autre exception politique.

La séquence institutionnelle était plus longue. Elle commençait par une autorité d'adressage réservant ou attribuant un bloc correctement aligné. Au début, les acteurs concernés comprenaient l'IANA, l'Internet Registry et le RIPE NCC. Leurs instruments étaient les procédures d'allocation alors en vigueur. Leurs décisions portaient sur la taille, l'alignement, le bénéficiaire et le contexte régional ou fournisseur du bloc. Le résultat immédiat vérifié était une allocation capable de subdivision hiérarchique. L'agrégation des routes dépendait encore d'acteurs ultérieurs.

Un fournisseur recevant un tel bloc pouvait sous-allouer des préfixes plus longs à ses clients. Pour un client connecté de manière unique, l'adressage tiré du bloc du fournisseur permettait à la joignabilité du client d'être couverte par l'agrégat du fournisseur en dehors de ce réseau. Le fournisseur avait toujours besoin d'une joignabilité interne détaillée pour ses propres clients. Une grande partie de l'économie profitait aux opérateurs distants sans défaut qui n'avaient plus à conserver chaque composant client comme une route externe distincte.

Le fournisseur décidait ensuite quelle plage agréger et où l'annoncer. RFC 1519 plaçait l'autorité d'agrégation auprès du domaine auquel la plage d'adresses était allouée, tout en permettant la délégation à un autre domaine. Elle recommandait des plages préconfigurées plutôt que de déduire les limites d'agrégation uniquement à partir des routes actuellement visibles. Un composant temporairement absent pourrait autrement être confondu avec un espace inutilisé. L'origine de l'agrégat avait également besoin d'un chemin de rejet pour les adresses à l'intérieur de l'agrégat qui manquaient d'une route composante joignable, empêchant les paquets de suivre une route moins spécifique en boucle.

« L'autorité exclusive » sur l'agrégation dans RFC 1519 faisait référence à la responsabilité de résumer une plage allouée. Elle ne donnait pas à l'initiateur de commandement sur les systèmes autonomes voisins, l'équipement client, les enregistrements d'adresses ou le traitement global des routes plus spécifiques. L'initiateur pouvait annoncer un agrégat. Chaque voisin conservait sa propre politique d'importation, de sélection et d'exportation.

La machinerie politique NSFNET de Merit constituait une autre surface de décision. Avant le CIDR, la base de données de routage politique enregistrait les numéros de réseau acceptés par le backbone et les systèmes autonomes dont les annonces étaient attendues. Les réseaux de niveau intermédiaire fournissaient des informations politiques; Merit les incorporait dans le matériel utilisé pour la configuration du backbone. RFC 1482 proposait d'étendre ce système pour comprendre les préfixes et les agrégats.

Le registre d'agrégation CIDR proposé enregistrerait le préfixe et la longueur, le système autonome d'origine, les systèmes autonomes annonceurs, les systèmes voisins et les contacts. Merit avait l'intention de définir des procédures d'enregistrement et de connecter les agrégats transportés via NSFNET aux processus de mise à jour de routage. Le registre était également conçu pour une utilisation plus large, et pas seulement pour les routes acceptées ou annoncées par NSFNET.

Un agrégat enregistré restait une déclaration politique. Il ne s'agissait ni d'un bloc d'adresses alloué ni d'une preuve d'annonce active. Il ne montrait pas que chaque voisin acceptait la route. Le fournisseur devait créer l'agrégat; les systèmes de transit devaient le propager; les opérateurs destinataires devaient l'autoriser et le sélectionner. Les noms, les allocations d'adresses, les origines de route, les délégations DNS inverse, les enregistrements politiques et l'état de transfert actif étaient des objets liés mais distincts.

Les éditeurs de logiciels fournissaient un autre prérequis. Un routeur devait coder des préfixes arbitraires, effectuer la sélection du préfixe le plus long, agréger les routes compatibles, préserver les informations de chemin requises, filtrer par préfixe et par masque, et coexister avec les systèmes plus anciens. Les éditeurs choisissaient les calendriers de publication et les ensembles de fonctionnalités. Les fournisseurs choisissaient si le code expérimental ou à version limitée était acceptable dans leurs réseaux. Les opérateurs effectuaient l'installation, la configuration, les tests d'interopérabilité, la surveillance et la correction des défauts.

L'acceptation à distance complétait le chemin. Un agrégat syntaxiquement valide pouvait toujours être rejeté par la politique d'un voisin. Une route plus spécifique valide pouvait être acceptée localement mais non exportée, acceptée uniquement d'un voisin particulier ou filtrée par un système distant. Une autorité d'adressage ne contrôlait pas ces décisions. La portée de l'agrégat émergeait d'un ensemble distribué de relations de routage.

L'avantage du CIDR reposait donc sur plusieurs actions liées: les autorités d'allocation créaient un espace agrégable; les fournisseurs alignaient les sous-allocations sur la topologie; les éditeurs fournissaient un code fonctionnel; les fournisseurs configuraient les agrégats; les systèmes politiques représentaient les annonces attendues; et les opérateurs voisins les acceptaient et les propageaient. Un échec à une étape pouvait préserver les routes composantes, produire une joignabilité incomplète ou retarder le déploiement.

Le calcul prospectif de NSFNET

RFC 1482 donnait une estimation contemporaine de ce que l'agrégation pourrait supprimer des annonces du backbone NSFNET. Publiée en juin 1993, elle commençait avec un ensemble d'entrée de 12 348 annonces présentées au backbone. Son algorithme recherchait les blocs d'adresses continus les plus longs et identifiait 4 135 annonces comme potentiellement supprimables, soit environ 33 % de cet ensemble d'entrée.

Le document qualifiait l'exercice d'estimation optimiste produite par un algorithme pessimiste. L'unité était une réduction prospective des annonces au sein de l'ensemble d'entrée nommé du backbone NSFNET. Il ne s'agissait pas d'une observation de la conformité des fournisseurs achevée, d'un décompte collecté après le déploiement ou d'une mesure de la charge administrative. La RFC ne fournissait pas de dénominateur à l'échelle d'Internet ni d'audit ultérieur montrant que chaque agrégat candidat avait été mis en œuvre.

La soustraction de la réduction potentielle déclarée de l'entrée donne 8 213 annonces restantes. Ce reste est un calcul d'analyste, pas un nombre rapporté comme une table observée par la RFC. Les différences politiques, les réseaux déconnectés, le multihébergement, les trous, les limitations logicielles et les choix des fournisseurs pouvaient tous modifier le résultat réalisé.

La valeur du calcul réside dans son mécanisme. Il montrait, avant le déploiement complet, qu'il existait une duplication substantielle au sein d'un ensemble d'annonces important. Il montrait également pourquoi les changements de base de données et de configuration étaient importants. Merit pouvait identifier des annonces contiguës dans les données politiques, mais les fournisseurs correspondants devaient encore former des agrégats, les annoncer via les relations de systèmes autonomes attendues et coordonner la transition.

RFC 1482 anticipait des changements dans les rapports, les outils, les formats de configuration, les pratiques d'enregistrement et le passage dercp_routedà GateD. Les fournisseurs analysant la sortie de Merit devraient adapter leurs processus. Le document énumérait également des questions non résolues concernant le débogage, la stabilité sous différentes topologies, les décisions de routage et le trafic envoyé dans des trous inaccessibles au sein d'un agrégat. Sa description de la mise en œuvre en cours doit être lue parallèlement à ces tâches ouvertes.

Il s'agissait d'un travail administratif au sens opérationnel ordinaire: tenir des registres corrects, attribuer les responsabilités, modifier les entrées logicielles, coordonner les origines attendues et diagnostiquer les défaillances. Il s'étendait à Merit, ANS, aux fournisseurs régionaux et de niveau intermédiaire, aux éditeurs, aux registres et aux opérateurs de systèmes autonomes. Le plan ne constituait pas la preuve qu'une institution approuvait chaque route ou contrôlait chaque mise en œuvre.

AlterNet: le côté fournisseur quantifié après déploiement

L'exemple de fournisseur mis en œuvre le plus solide apparaît dans RFC 2008. Elle rapporte qu'en octobre 1995, AlterNet transportait 3 194 routes en interne et annonçait 799 routes vers le reste d'Internet. La différence est de 2 395 annonces, soit environ 75 % du nombre interne d'AlterNet.

La mesure a une frontière de fournisseur claire. La première unité est une route à l'intérieur d'AlterNet; la seconde est une route annoncée à l'extérieur après agrégation. La base de comparaison est l'ensemble interne d'AlterNet lui-même. Elle démontre qu'un fournisseur pouvait conserver des détails clients ou internes tout en exportant une représentation beaucoup plus petite vers ses voisins.

La provenance est limitée. RFC 2008 attribue les chiffres à une communication privée d'octobre 1995 d'Andrew Partan. Elle n'identifie pas le routeur ou le collecteur spécifique, ne fournit pas de vidage archivé, ne documente pas la commande de collecte, ni n'indique comment les routes plus spécifiques étaient classées séparément dans chaque ensemble. Le résultat est une preuve de fournisseur reproduite dans un document de normes, plutôt qu'une mesure globale récupérable indépendamment.

La mise en œuvre observée importe néanmoins. AlterNet avait formé des agrégats suffisants pour transformer des milliers de routes internes en centaines d'annonces externes. Les voisins acceptant ces annonces évitaient de transporter 2 395 détails d'AlterNet en tant qu'entrées séparées. C'est un côté après direct pour le mécanisme de compression, limité à un fournisseur et à une observation rapportée.

L'acteur était AlterNet. L'instrument était l'agrégation du fournisseur incarnée dans sa configuration de routage et ses annonces exportées. Le réseau affecté était l'ensemble de routes internes d'AlterNet et les relations de routage externes par lesquelles les 799 annonces étaient envoyées. La mise en œuvre est attestée par les décomptes avant-après. La source ne divulgue pas de chemin de révision formel, de procédure d'exception, de processus de recours, d'enregistrement de renumérotation des clients ou de test final de joignabilité.

Ces éléments manquants empêchent l'affaire d'étayer un récit général sur le pouvoir exercé. Les chiffres montrent qu'AlterNet a choisi une abstraction externe de sa joignabilité interne. Ils ne montrent pas qu'AlterNet a forcé 2 395 clients à renuméroter, que chaque voisin a accepté chaque annonce, ou que la route plus spécifique d'un client nommé a été rejetée. L'affaire établit une performance d'ingénierie et un point de contrôle du fournisseur.

RFC 2008 place le chiffre d'AlterNet à côté de deux quantités d'octobre 1995 qui doivent rester séparées. L'Internet Routing Registry contenait 61 430 préfixes uniques, à l'exclusion des enregistrements marqués comme retirés. La RFC indiquait également que moins de 30 000 routes apparaissaient dans la partie sans défaut du système de routage. Le premier ensemble se compose de préfixes uniques enregistrés selon la règle de retrait énoncée par la RFC. Le second concerne les entrées de routage actives sans défaut, mais la communication privée citée n'identifie pas le collecteur ou le point d'observation et ne rapporte pas le traitement des routes plus spécifiques.

Les intentions enregistrées, les allocations, les routes internes et les annonces externes actives sont des populations non équivalentes. Le registre était incomplet et pouvait contenir des préfixes non actifs à un point d'observation donné. Une table de routage pouvait contenir des routes actives absentes du registre. La différence entre 61 430 et moins de 30 000 ne peut pas être convertie en pourcentage de compression global.

AlterNet est par conséquent le seul côté fournisseur quantifié après déploiement dans les documents d'époque accessibles utilisés ici. Cela suffit à confirmer que le mécanisme a fonctionné à une échelle significative au sein d'un fournisseur majeur. C'est insuffisant pour des conclusions représentatives sur les opérateurs en tant que catégorie.

Plans, états du code et cas incomplets

RFC 1467 offre une visibilité inhabituellement utile sur les préparatifs des fournisseurs et des éditeurs en 1993. La plupart des entrées capturent la planification, les tests, la capacité installée ou les versions prévues plutôt qu'un résultat d'agrégation ultérieur.

ESNET illustre cette étape préparatoire. Le volume d'informations de configuration décrivant les réseaux qu'il devait accepter de ses voisins pesait déjà sur un stockage non volatile limité. ESNET s'attendait à ce que l'agrégation l'aide, a choisi d'attendre la version complète du logiciel BGP-4 et a déclaré qu'il passerait à des systèmes Cisco CSC-4 entre-temps. Le dossier identifie donc un opérateur nommé, une contrainte opérationnelle définie, une décision de risque logiciel et une réponse matérielle prévue. Son récit s'arrête à ces intentions, avant l'achèvement de la mise à niveau, le déploiement de BGP-4, la formation d'agrégats, les changements de filtres ou une conséquence mesurée sur la capacité ou la joignabilité. ESNET appartient au contexte de déploiement plutôt qu'à côté d'AlterNet comme cas mis en œuvre.

D'autres entrées révèlent l'environnement hétérogène dans lequel le déploiement a eu lieu. SprintLink et ICM avaient installé des routeurs CSC-4 et avaient l'intention de transporter le routage complet, y compris les routes en dehors des ensembles politiques NSFNET/ANSNET. ANSNET avait mis à niveau ses routeurs vers AIX 3.2 et testait le code BGP-4, tandis que les anciens logiciels attendaient toujours leur remplacement pour un support cohérent. Ailleurs, des mises à niveau matérielles ou de système d'exploitation terminées côtoyaient des tests de code internes, des capacités projetées et des versions planifiées. Pris ensemble, ces rapports expliquent pourquoi un objectif architectural commun a produit des états de préparation opérationnelle inégaux.

L'enquête sur les fournisseurs donne une cause concrète au jalon manqué de juin 1993. Certaines implémentations pouvaient recevoir une joignabilité sans classe tout en manquant d'agrégation; la désagrégation contrôlée était une autre capacité distincte. La maturité des versions a façonné les dates auxquelles les fournisseurs pouvaient prendre le risque de déploiement, et le propre matériel et les systèmes politiques des fournisseurs déterminaient ce que chaque version pouvait accomplir localement.

Le rapport final de Merit ajoute une confirmation au niveau du programme que le CIDR a atteint le backbone NSFNET en 1994. La série SURFnet de Huston enregistre ensuite l'inflexion à l'échelle de la table visible depuis un point d'observation sans défaut. Ces sources décrivent différents niveaux de la transition: le déploiement du programme et l'effet de routage externe. AlterNet seul fournit une comparaison quantifiée entre l'interne du fournisseur et l'externe.

Le dossier dépeint donc une préparation variée plutôt qu'un échantillon représentatif des résultats des fournisseurs. Les réseaux différaient en matériel, bases de données politiques, utilisation des valeurs par défaut, maturité du code, relations externes et exposition aux routes en dehors de l'environnement NSFNET. Ces différences comptent lors de l'interprétation du ratio de compression d'AlterNet, qui reste la preuve de la mise en œuvre d'un fournisseur majeur plutôt qu'une moyenne à l'échelle de la catégorie.

Renumérotation et limite de la permission du protocole

RFC 1519 prenait en compte un client qui changeait de fournisseur sans renuméroter immédiatement. Le nouveau fournisseur pouvait annoncer une route plus spécifique à l'intérieur de l'agrégat de l'ancien fournisseur. La correspondance par préfixe le plus long dirigerait le trafic vers le nouveau rattachement partout où cette route plus spécifique était acceptée. Le document encourageait la migration éventuelle dans le bloc d'adresses du nouveau fournisseur, car chaque exception conservée affaiblissait l'agrégation.

Cet arrangement créait une pression opérationnelle sans commande au niveau du protocole de renuméroter. Le client pouvait conserver ses adresses dans le format de paquet. Le nouveau fournisseur pouvait créer la route spécifique. L'ancien fournisseur pouvait continuer d'annoncer son agrégat plus large. La joignabilité dépendait alors de l'acceptation et de la propagation du préfixe plus long par les opérateurs distants.

RFC 2008 décrit cette dépendance à travers un exemple schématique de changement de fournisseur. Même avec l'autorisation de l'ancien fournisseur et une annonce du nouveau fournisseur, les systèmes distants pouvaient refuser ou ne pas avoir la capacité d'accepter la route plus spécifique. Une connectivité partielle pouvait s'ensuivre. Le document présente la renumérotation ou le service via des fournisseurs disposés à soutenir la route comme des réponses possibles. Son ancien fournisseur, son nouveau fournisseur, les systèmes distants et l'organisation affectée sont illustratifs plutôt que des entités nommés dans un cas observé, laissant l'incidence, l'examen, le recours et la joignabilité finale en dehors du récit subsistant.

RFC 1900, publiée en février 1996, fournit des preuves directes sur l'état de la pratique de la renumérotation. Elle caractérise la renumérotation comme coûteuse, fastidieuse et sujette aux erreurs, nécessitant une expertise et une planification préalable. Les outils étaient peu nombreux et pas largement déployés; les procédures documentées et l'expérience partagée étaient rares.

Ses préoccupations techniques spécifiques incluent les fichiers de configuration tenus par des humains, les applications contenant des adresses IP littérales, les mappages qui devraient plutôt être résolus via le DNS, et les licences liées aux adresses d'hôte. Elle recommande de s'appuyer davantage sur les noms de domaine pleinement qualifiés, la génération automatisée de données de configuration, DHCP, les mises à jour DNS dynamiques, la découverte de routeurs et les outils de renumérotation d'hôte. L'évaluation de l'IAB établit que les outils de portabilité étaient en retard par rapport à la transition du routage. Le coût moyen, le temps de migration, la fréquence des échecs et la proportion d'organisations qui ont renuméroté restent non mesurés dans le document.

RFC 2008 proposait une politique de « prêt d'adresse » selon laquelle les adresses associées à une relation avec un fournisseur seraient restituées lorsque cette relation prendrait fin. Publiée en octobre 1996 en tant que meilleure pratique actuelle, elle recommandait un délai de grâce d'au moins 30 jours et suggérait pas plus de six mois pour limiter les frais généraux de routage. Ces durées exprimaient des orientations politiques plutôt que des moyennes mesurées de l'industrie.

La recommandation liait la continuité de l'adresse à la topologie de service de manière plus explicite que ne l'exigeait le format de paquet du CIDR. Un registre Internet associé à un fournisseur pouvait fournir des adresses selon des conditions liées à l'accord de service; le fournisseur organiserait une agrégation suffisante; le client renuméroterait après avoir changé de fournisseur. Son modèle prescrit s'adresse aux abonnés recevant de telles attributions, tandis que l'adoption réelle, les modalités d'appel et les résultats pour les clients dépassent les preuves du document.

Le multihébergement compliquait encore le tableau. Un réseau connecté via plusieurs fournisseurs pouvait avoir besoin d'une route plus spécifique visible par plus d'un chemin. RFC 1519 traitait le multihébergement comme une source continue d'état non agrégé et utilisait des hypothèses sur sa croissance dans le modèle de projection. L'agrégation des fournisseurs était donc conçue avec des exceptions plutôt que comme une règle absolue.

Les opérateurs distants pouvaient distinguer les agrégats ordinaires des exceptions par la politique de routage, tout en conservant un contrôle indépendant sur l'acceptation et l'exportation. Une route plus spécifique autorisée par BGP-4 pouvait échouer à un test de politique locale; un préfixe accepté pouvait ne pas voyager plus loin que le voisin acceptant. La permission du protocole, la sélection locale, les relations commerciales et la pression opérationnelle restaient séparées.

La surface administrative élargie

L'« administrateur » du titre est mieux compris comme une surface administrative distribuée. Le CIDR a accru la conséquence des décisions qui alignaient l'adressage, la topologie, la politique de routage et les logiciels. L'autorité résultante était répartie entre les institutions et les couches opérationnelles plutôt que concentrée en un seul point de commandement.

Au niveau de l'allocation, l'IANA reconnaissait les registres régionaux et attribuait de grandes plages; l'Internet Registry desservait les régions sans registre régional établi; et le RIPE NCC administrait les blocs européens dans le cadre du plan émergent. Les fournisseurs subdivisaient ensuite les plages contiguës pour les clients connectés. Ces rôles spécifiques à la période formaient une hiérarchie de l'administration des adresses, mais chaque rôle s'arrêtait avant de déterminer comment chaque route en aval serait créée ou acceptée.

RFC 1518 expliquait le compromis derrière cette hiérarchie. L'administration pouvait rester décentralisée tandis qu'une abstraction efficace nécessitait que les attributions de niveau inférieur suivent la topologie par laquelle la joignabilité voyageait. Les détails disparaissaient le plus efficacement près des feuilles: le fournisseur direct conservait les routes des clients tandis que les systèmes distants sans défaut recevaient un résumé. Cela distribuait le travail d'attribution d'adresses vers l'extérieur et rendait la relation du fournisseur entre la sous-allocation et la topologie plus conséquente.

L'agrégation introduisait une deuxième couche de responsabilité. Un fournisseur sélectionnait la plage, créait ou déléguait l'agrégat, préservait la joignabilité des composants et installait des protections pour les trous. De nombreuses destinations pouvaient alors dépendre de l'exactitude d'une seule déclaration externe. L'abstraction réduisait l'état distant tout en concentrant la responsabilité de configuration à son origine.

Merit occupait un rôle politique lié mais distinct au sein du service NSFNET. Il enregistrait les origines attendues, recevait des informations des réseaux entités, traduisait la politique en configuration de backbone, et proposait d'étendre ces processus aux agrégats. Ce rôle a façonné l'enregistrement et la configuration NSFNET sans remplacer l'allocation d'adresses ni les politiques de routage des autres systèmes autonomes.

Les logiciels et l'interconnexion complétaient la chaîne. Les éditeurs déterminaient quand les fonctions prenant en charge les préfixes étaient suffisamment matures pour être livrées; les fournisseurs décidaient quand les installer et leur faire confiance; les opérateurs configuraient, testaient et surveillaient les systèmes résultants. Les systèmes autonomes voisins exerçaient ensuite leurs propres politiques d'importation, de sélection et d'exportation. La portée pratique d'un agrégat s'assemblait à travers ces relations.

Les réseaux finaux conservaient leurs propres décisions concernant la connectivité, le multihébergement, la configuration locale et la renumérotation. Ces choix s'opéraient dans les contraintes fixées par les conditions d'attribution des fournisseurs, l'acceptation des routes à distance, les outils disponibles et les charges opérationnelles décrites dans RFC 1900. Ils étaient entités au système, bien que leur liberté de conserver une adresse lors d'un changement de fournisseur dépende de décisions extérieures à la relation directe.

Le rôle de l'IETF était architectural et de coordination. Ses documents définissaient un comportement interopérable et fournissaient des forums de déploiement; l'allocation, l'installation de logiciels, la création d'agrégats et l'acceptation des routes restaient aux acteurs opérationnels correspondants. L'autorité des normes créait un cadre commun à travers lequel ces décisions interagissaient.

Le CIDR a ainsi redistribué les responsabilités autour de la frontière d'abstraction. Les autorités d'allocation façonnaient si l'espace était agrégable. Les fournisseurs regroupaient les destinations et maintenaient les détails cachés. Merit a adapté la machinerie politique pour un environnement de backbone majeur. Les éditeurs contrôlaient la préparation des fonctionnalités. Les voisins acceptaient ou rejetaient les annonces et les exceptions. Les réseaux finaux géraient les conséquences pour le rattachement et la portabilité. Le gain partagé dépendait de tous, même si aucun n'administrait seul le système de routage.

Des coûts qui se sont déplacés plutôt que de disparaître

L'avantage partagé apparaissait dans les tables de routage distantes. Un fournisseur pouvait cacher de nombreuses routes client à l'intérieur d'une seule annonce externe, réduisant la mémoire, le traitement, la configuration et le travail de mise à jour ailleurs. La comparaison rapportée par AlterNet en fournit un exemple concret.

Le fournisseur direct continuait de détenir les détails internes. Il devait atteindre les clients individuels, maintenir les sous-allocations, configurer les agrégats, préserver les routes d'exception, mettre à jour les enregistrements et diagnostiquer les trous. L'agrégation déplaçait les informations et les responsabilités vers les réseaux à l'origine de l'abstraction.

Les autorités d'adressage réduisaient la pression de traiter chaque allocation de manière centralisée en déléguant les fonctions régionales et au niveau des fournisseurs. Les registres régionaux et les fournisseurs effectuaient alors davantage de travail d'allocation et d'enregistrement plus près de la topologie. La charge administrative s'est déplacée vers l'extérieur depuis l'autorité centrale.

Le registre d'agrégation proposé par Merit illustre un nouveau coût de coordination. Une fois que de nombreuses routes pouvaient être représentées par un seul préfixe, les opérateurs avaient besoin d'informations fiables sur qui était à l'origine de cette abstraction, quels voisins la recevaient et comment les changements de politique devaient être synchronisés. La compression réduisait l'état de transfert tout en augmentant l'importance des métadonnées et de l'exactitude de la configuration.

Les éditeurs supportaient le travail de développement et d'interopérabilité. Les fournisseurs supportaient le risque de déploiement. Les opérateurs traduisaient la politique en filtres prenant en compte les préfixes et surveillaient les changements de joignabilité involontaires. Les clients ont eu accès à des blocs d'adresses mieux adaptés à leurs besoins et, lorsqu'ils étaient connectés de manière unique, évitaient d'ajouter des routes globales distinctes. Un changement ultérieur de fournisseur pouvait les exposer à la renumérotation ou à la dépendance aux exceptions.

La répartition incluait plusieurs effets simultanés. Les opérateurs distants ont bénéficié d'un allégement de la table. Les fournisseurs directs ont assumé des responsabilités d'abstraction. Les fonctions d'allocation sont devenues plus distribuées. Les éditeurs ont construit du nouveau code. Certains clients ont reçu un service efficace sans route globale; d'autres ont été confrontés à des questions de portabilité futures. Le dossier accessible établit ces catégories de travail plus clairement que leur incidence financière.

La conservation des adresses doit rester distincte de l'agrégation. L'émission d'une collection de réseaux de classe C de taille appropriée au lieu d'une classe B pouvait conserver un espace d'adressage limité. Annoncer chaque composant indépendamment pouvait encore augmenter l'état de routage. L'agrégation ne réduisait les annonces externes que lorsque les composants d'adresse partageaient un chemin topologique et que les opérateurs utilisaient le mécanisme sans classe.

Le DNS inverse était une autre fonction distincte. Les allocations alignées sur les bits ne correspondaient pas toujours aux limites d'octets de la structure de délégation DNS inverse existante, créant des questions de maintenance supplémentaires. Résoudre ces questions ne créait pas une route BGP, et un agrégat de routage ne configurait pas automatiquement le DNS.

De même, une entrée dans une base de données de politique de routage différait d'une annonce active. Un préfixe enregistré exprimait la politique prévue ou le contexte d'autorisation. Une entrée BGP active reflétait ce qu'un collecteur recevait et sélectionnait. Traiter les deux comme interchangeables transformerait les décomptes IRR et sans défaut de RFC 2008 en un pourcentage trompeur.

L'alternative avec des routeurs plus grands et des spécificités plus lâches

Un contrefactuel plausible de l'époque se serait appuyé plus lourdement sur des routeurs plus grands, aurait accepté les routes plus spécifiques plus librement et aurait émis davantage d'espace indépendant du fournisseur. Il aurait pu réduire la pression immédiate de renumérotation et permettre aux clients de conserver leurs adresses lors des changements de fournisseur. Ses coûts seraient apparus dans l'état de routage, le traitement des mises à jour, la configuration et la gestion des défaillances.

Plus de mémoire pourrait augmenter le nombre d'entrées conservées par un routeur. Des processeurs plus rapides pourraient améliorer la sélection des routes et le traitement des mises à jour. Des stockages de configuration plus grands pourraient contenir plus de filtres. Les informations sous-jacentes resteraient non compressées: chaque préfixe client visible indépendamment nécessiterait un stockage et un traitement politique sur chaque système sans défaut qui l'accepte.

Les rapports de fournisseurs de 1993 montrent pourquoi la capacité ne pouvait pas être traitée comme un plafond uniforme. Différents réseaux étaient contraints par la mémoire de la table de transfert, les informations de chemin, la capacité du processeur, le stockage de configuration, ou l'interaction entre eux. Une mise à niveau matérielle qui résolvait une limite locale pouvait laisser un autre goulot d'étranglement opérationnel intact.

Une table plus grande modifiait également le travail de convergence et de mise à jour. Plus de routes signifiait plus d'entrées à comparer, installer, retirer et annoncer lorsque la topologie changeait. Un système sans défaut plus détaillé traitait donc plus d'état après chaque changement, bien que les preuves d'époque ne fournissent aucune estimation numérique complète du délai de convergence résultant, du coût en bien-être ou de l'exposition aux pannes.

Une acceptation plus lâche des routes plus spécifiques faciliterait la portabilité et le multihébergement. Un client conservant un préfixe d'un ancien fournisseur pourrait l'annoncer via un nouveau fournisseur. Un réseau multihébergé pourrait exposer différents chemins. Les opérateurs distants paieraient le coût récurrent de conservation et de mise à jour de cette exception.

Si l'espace indépendant du fournisseur devenait courant à la granularité des sites finaux, le système de routage se rapprocherait d'une énumération plus plate des sites connectés. Cela répartirait l'exposition aux défaillances sur de nombreuses annonces distinctes et répartirait le travail de configuration et de maintenance des politiques entre les opérateurs sans défaut.

L'agrégation créait une forme de risque différente. Un agrégat provenant d'un fournisseur représentait de nombreuses destinations. Une mauvaise configuration, un retrait ou un comportement de rejet incorrect à cette origine pouvaient affecter une plus grande plage d'adresses à la fois. La défaillance était potentiellement concentrée au point d'abstraction. Les opérateurs avaient donc besoin d'une joignabilité précise des composants et de protections contre les boucles ou les trous noirs.

La voie des nombreuses spécificités offrait des annonces indépendantes pour les destinations individuelles. Ses défaillances étaient plus distribuées, tout comme sa charge en état ordinaire: chaque table distante, ensemble de politiques et processus de mise à jour portait plus de détails. Le choix d'ingénierie équilibrait un plus petit ensemble d'abstractions conséquentes par rapport à un plus grand ensemble de faits maintenus indépendamment.

Le stockage de configuration importait également. La difficulté rapportée par ESNET concernait les informations de politique décrivant les réseaux à accepter, plutôt que seulement la mémoire de transfert. Une acceptation plus lâche pourrait réduire certaines restrictions explicites, mais un opérateur soucieux de l'origine de la route ou de la politique client aurait toujours besoin d'un état de configuration. Une population de préfixes plus grande et plus dynamique rendait ce problème de maintenance plus difficile à borner.

Une allocation plus indépendante des fournisseurs pourrait améliorer la portabilité du changement. Elle affaiblirait l'alignement entre la hiérarchie d'adresses et la topologie des fournisseurs, réduisant la part des destinations cachées à l'intérieur des agrégats des fournisseurs. Les sources d'époque ne contiennent aucune hiérarchie de substitution déployée avec une compression démontrée comparable.

Le contrefactuel semble donc techniquement possible pendant un certain temps, surtout avec des mises à niveau matérielles continues et des valeurs par défaut sélectives. Sa durée réalisable, son coût total et ses effets sur le bien-être des clients restent en dehors des mesures disponibles. Les contraintes de capacité documentées expliquent néanmoins pourquoi les ingénieurs ont cherché à changer la relation de croissance plutôt que d'élever à plusieurs reprises les plafonds d'équipement.

Une version plus solide de la voie CIDR

L'alternative la plus crédible était le CIDR accompagné d'un meilleur support de la portabilité, d'exceptions documentées et d'un examen plus clair. Cette voie conservait l'agrégation topologique tout en répondant à la charge opérationnelle visible en 1996.

Les conditions d'attribution auraient pu indiquer si un bloc d'adresses était lié à une relation avec un fournisseur, ce qui se passerait après résiliation et combien de temps un chevauchement pourrait durer. Le fournisseur perdant un client pourrait préciser s'il continuerait à couvrir la plage d'adresses dans son agrégat. Le nouveau fournisseur pourrait indiquer s'il annoncerait la route plus spécifique.

Les grands opérateurs de transit pourraient publier les conditions de préfixe et d'origine qu'ils appliquaient aux exceptions temporaires. Une telle publication révélerait si une transition proposée avait un chemin de joignabilité plausible, tandis que chaque opérateur distant conservait sa politique indépendante. Un client pourrait tester le plan avant de changer de service plutôt que de découvrir le filtrage après coup.

Un processus d'examen pourrait identifier l'acteur responsable d'un refus, la raison technique, la durée et le recours disponible. Certains cas pourraient justifier une acceptation temporaire; d'autres pourraient nécessiter une renumérotation. La décision resterait opérationnelle, mais sa portée et sa conséquence seraient visibles.

Les recommandations de RFC 1900 indiquent les outils nécessaires du côté client: configuration basée sur le DNS, moins d'adresses littérales, DHCP, mises à jour dynamiques, automatisation et procédures partagées. Un déploiement plus précoce et plus large de ces pratiques aurait pu réduire la difficulté de la renumérotation. La direction probable de cet avantage est claire, tandis que son ampleur reste non mesurée.

Une route plus spécifique temporaire dépendait également de systèmes en dehors de la relation directe avec le fournisseur. Un accord bilatéral pouvait organiser la création et la gestion locale, tandis que la propagation à l'échelle d'Internet continuait de dépendre d'autres systèmes autonomes. La documentation et l'examen pourraient rendre cette dépendance visible sans transformer un organisme en garant de la joignabilité universelle.

Le contrefactuel le plus solide est donc une transition plus responsable au sein d'un système de routage qui continue d'agréger. L'objectif de compression du CIDR restait convaincant. De meilleurs outils et une gestion explicite des exceptions auraient pu rendre les coûts supportés par les réseaux en mouvement plus faciles à anticiper et à contester.

Le dossier d'époque subsistant identifie les garanties manquantes plus facilement que leur prévalence. Il ne contient aucun dossier client complet permettant de mesurer la fréquence à laquelle un tel cadre existait ou comment les fournisseurs traitaient les exceptions raisonnables dans l'ensemble de la population.

Ce que les preuves permettent

Les preuves d'ingénierie forment une chaîne cohérente, bien qu'imparfaite. RFC 1519 fournit une série de routes de 1988–1992 provenant de Merit et des projections explicites. RFC 1467 enregistre le taux de la base de données politique de 1993, les changements d'allocation, le jalon manqué, les états des fournisseurs et les contraintes des fournisseurs. RFC 1482 documente les changements opérationnels prévus par Merit et le calcul prospectif de l'agrégation. Le rapport final de Merit, dont la copie accessible ne fournit pas de date de publication explicite, situe le déploiement du CIDR sur NSFNET en 1994. Huston reconstitue l'inflexion de 1994–1995 à partir des mesures de SURFnet. RFC 2008 fournit la comparaison interne-externe d'AlterNet. RFC 4632 offre une corroboration ultérieure de la communauté des normes.

Les premiers décomptes appartiennent aux contextes NSFNET ou NSFNET/ANSNET plutôt qu'à un recensement à l'échelle d'Internet. RFC 1482 enregistre une conception et un calcul prospectifs. L'historique de Huston assemble des collecteurs et laisse non divulgué le traitement des routes plus spécifiques dans le total de 1994. RFC 2008 s'appuie matériellement sur des communications privées et laisse le collecteur derrière son décompte sans défaut non spécifié. RFC 4632 est un récit rétrospectif de la communauté des normes plutôt qu'un audit administratif contemporain. Ces limites bornent l'échelle et la reproductibilité du verdict quantitatif.

Dans cette limite, les sources soutiennent un allégement substantiel du routage cohérent avec l'agrégation CIDR aux points d'observation observés. Elles ne soutiennent ni un décompte de table universel ni une estimation causale précise par rapport à l'avenir sans action non observé de RFC 1519. Le plateau de 1994 et la projection occupent également des dates différentes: l'horizon de trois ans de RFC 1519 commence avec sa base de référence de janvier 1992.

Le dossier administratif est le plus solide au niveau de la structure et du flux de travail. Il identifie les décisions en matière d'allocation, de sous-allocation, d'agrégation, d'enregistrement, de publication de logiciels, d'acceptation des routes, d'exceptions et de renumérotation. Les entrées de fournisseurs de RFC 1467 s'arrêtent pour la plupart à la capacité, à l'état du code, à l'évaluation des risques ou au plan. ESNET enregistre une réponse prospective à la pression de configuration. Le rapport de Merit fournit un témoignage de déploiement au niveau du programme. AlterNet fournit le seul côté fournisseur quantifié après déploiement dans l'ensemble accessible.

Aucun deuxième cas de fournisseur nommé ne complète la chaîne complète de la décision et de l'instrument à la mise en œuvre et à la conséquence mesurée. Les sources ne contiennent également aucun dossier client nommé suivant un rejet de route plus spécifique à travers l'examen, le recours, la renumérotation terminée ou la joignabilité restaurée. RFC 1900 caractérise la charge de renumérotation contemporaine mais ne fournit aucun dénominateur de population, coût moyen, durée ou fréquence des échecs. RFC 2008 énonce des recommandations politiques et des mécanismes structurels sans établir une adoption universelle ou des résultats représentatifs pour les clients.

Le dossier contrefactuel est de même qualitatif. Il établit des contraintes matérielles et de configuration hétérogènes, l'état récurrent requis par les routes plus spécifiques et la concentration du risque aux origines des agrégats. Il ne fournit aucun déploiement alternatif complet à partir duquel calculer le délai de convergence, le coût total, l'incidence des pannes, la durée réalisable ou le bien-être des clients. Les affirmations sur la direction mieux étayée de ces effets doivent rester distinctes des estimations numériques.

Ce qui subsiste est suffisant pour identifier des capacités conséquentes. Les autorités d'allocation ont façonné si les blocs pouvaient être agrégés. Les fournisseurs ont choisi l'abstraction exportée de leurs détails internes. Merit a façonné les enregistrements politiques et la configuration pour l'environnement NSFNET. Les éditeurs ont affecté le calendrier de déploiement. Les systèmes autonomes voisins ont décidé ce qu'ils acceptaient et propageaient. Les réseaux finaux ont navigué entre l'attribution, le multihébergement, la portabilité et les coûts de renumérotation locaux.

La fréquence et la distribution restent non résolues. Les sources ne montrent pas à quelle fréquence les fournisseurs ont refusé des exceptions, combien de clients ont renuméroté, comment l'examen fonctionnait ou quels acteurs ont finalement supporté le plus grand coût. L'administrateur élargi du titre décrit donc un champ élargi de responsabilité opérationnelle, étayé par l'architecture, les plans, les preuves de mise en œuvre et un cas de fournisseur quantifié. Ce n'est ni une mesure démographique de l'effet de levier exercé ni une affirmation selon laquelle un dirigeant a acquis le contrôle.

Un verdict proportionné

Le CIDR a produit un allégement substantiel du routage aux points d'observation observés de 1994–1995. La reconstruction basée sur SURFnet de Huston est restée proche de 20 000 entrées en 1994, et le rapport d'octobre 1995 d'AlterNet montre le mécanisme directement: 3 194 routes internes représentées par 799 annonces externes, une différence de 2 395.

La projection de 75 000 routes sans action de RFC 1519 fournit un contexte historique plutôt qu'un test de prévision aligné sur les dates. Son horizon de trois ans commençait à partir de la base de référence de janvier 1992, tandis que le plateau d'environ 20 000 entrées de Huston décrit des observations en 1994. Les dates ne coïncident donc pas exactement. La comparaison montre que la voie observée à l'ère du déploiement était beaucoup moins sévère que l'avenir modélisé sans action; elle ne convertit pas cet avenir en un contrefactuel observé.

Le moment et le mécanisme s'alignent sur le récit rétrospectif d'une forte baisse en 1994 et d'une croissance à peu près linéaire après le milieu de cette année-là. La pratique d'allocation avait changé, des blocs fournisseurs existaient, des logiciels sans classe atteignaient les réseaux, les agrégats remplaçaient les composants, et AlterNet démontre la compression interne-externe disponible pour un fournisseur.

L'obtention de ce résultat a nécessité une action distribuée, spécifique à la période. L'IANA, l'Internet Registry et le RIPE NCC ont changé la pratique d'allocation. Merit a repensé la machinerie politique. Les éditeurs ont construit et publié du code de routage sans classe. Les fournisseurs l'ont installé, ont formé des agrégats et ont conservé les détails internes. Les systèmes autonomes voisins ont appliqué leurs propres politiques de routage. Les réseaux finaux ont fonctionné dans les contraintes de portabilité et de multihébergement qui en résultaient.

Ces actions ont créé des points de décision conséquents dont l'autorité structurelle est mieux documentée que leur exercice à l'échelle de la population. AlterNet reste le seul côté fournisseur quantifié après déploiement dans l'ensemble accessible; ESNET enregistre un plan; et les sources subsistantes ne contiennent aucun cas client nommé complétant le chemin de l'exception ou du rejet à travers l'examen, le recours et la joignabilité finale.

Le CIDR a sauvé la table dans un sens défendable et limité: il a arrêté la trajectoire de croissance visible de 1994 et a permis à de nombreuses routes d'être représentées par moins d'annonces. Il a élargi l'administrateur dans un sens également limité: une abstraction réussie nécessitait une responsabilité plus explicite pour les allocations, les limites d'agrégation, les enregistrements politiques, les logiciels, les exceptions et l'acceptation.