Résumé
- RIPE-81 explicite la conversion entre politiques et configuration ; un témoignage de 1993 documente un essai limité, pas une adoption générale.
- L’accord de 1994 séparait description du routeur et configuration ; le RFC informatif de 1995 ne prouve pas une exécution universelle.
RIPE-81 partait d’une difficulté pratique : le routage européen n’avait pas de cœur unique et coordonné, et les réseaux décrivaient différemment leurs relations de transit. La proposition de février 1993 consistait à représenter ces politiques sous forme d’objets structurés dans la base RIPE. Elles devaient être claires, générales, vérifiables et applicables. Le document demandait aussi une traduction dans les deux sens entre politique et fichiers de configuration des routeurs.
Traduire ne signifiait pas commander à distance. Une base pouvait conserver une politique déclarée ; un programme pouvait la convertir en listes d’accès Cisco ou gated ; l’opérateur pouvait examiner puis charger le résultat. La configuration présente sur le routeur, les annonces BGP et les observations de trafic constituaient ensuite des preuves distinctes. Une entrée ne démontrait pas que les étapes suivantes lui correspondaient.
Le courriel de Tony Bates du 22 février 1993 fournit un détail rare sur la mise en œuvre. Il indiquait que ripe-81 attendait encore sa ratification. Un prototype élémentaire générait des listes Cisco et gated ; un pilote « très petit » au NCC utilisait une pseudo-base de données. Bates mentionnait aussi des outils naissants de trace et de configuration. Cela atteste un prototype et un essai limité, pas un déploiement général. Dire qu’aucune génération n’existait serait faux ; transformer ce pilote en mesure d’adoption le serait aussi.
Les comptes rendus de RIPE 18 situent le travail à côté du Merit Routing Registry, des serveurs de routes et de la transition du NSFNET. Ils citent quatre AS dans le registre Merit et une version bêta du Routing Policy Server. C’est un instantané de réunion, non un dénombrement des réseaux utilisateurs ni la preuve qu’un registre pilotait la transition.
Une politique décrit des relations : quels voisins transportent le trafic, quelles destinations sont privilégiées et dans quelles conditions. Un format partagé facilite l’échange et la comparaison. L’opérateur connaît toutefois ses contrats, ses équipements et le coût d’une erreur. La syntaxe commune réduit le travail de coordination sans transférer la décision locale au gestionnaire de la base.
La limite fut explicitée avec l’objet inet-rtr. Il devait décrire les interfaces d’un routeur et ses relations de peering pour des outils comme PRIDE. Les minutes de septembre 1994 consignent l’accord : cet objet ne devait pas servir à configurer les routeurs. Cette règle concerne l’objet descriptif ; elle n’efface pas le témoignage antérieur sur la génération de listes depuis d’autres données. Générer et appliquer restent deux actes différents.
RIPE-181 révisa la représentation. Le RFC 1786, publié en mars 1995, décrit les objets aut-num et route, reprend les contributions de RIPE et Merit et envisage des outils comparant la politique enregistrée au routage observé. Il est informatif. Sa formule selon laquelle les routes non décrites ne devraient jamais être routées exprime une norme de conception, pas une preuve d’application universelle. Un objet route n’est pas une annonce BGP ; un fichier produit n’est pas une configuration chargée ; et cette configuration ne prouve pas seule le trajet des paquets.
L’historique actuel de la base RIPE date rétrospectivement la création de l’Internet Routing Registry de 1995 et décrit sa séparation ultérieure des données d’allocation. Cette chronologie ne comble pas l’écart entre prototype et pratique courante. Le point historique est plus circonscrit : RIPE rendait les politiques transportables et fournissait des entrées aux outils, tandis que le groupe délimitait le contrôle des équipements. « The Policy Mirror » de Heng Lu propose une grille d’interprétation, pas une preuve historique. Le registre pouvait aider à préparer un filtre ; l’opérateur décidait de l’appliquer.
Sources
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
