Résumé

  • Un projet individuel daté du 2 novembre propose de mesurer, d’une part, le temps écoulé entre le premier PDU RTR pertinent et la stabilisation des tables BGP RIB et FIB et, d’autre part, le temps entre l’installation des VRP et cette même stabilisation.
  • Le premier intervalle comprend le transport RTR, l’installation, la nouvelle validation des routes et la convergence BGP. Le second commence après une partie de ce travail. Le projet demande d’identifier le chronomètre lorsqu’un rapport n’en publie qu’un.
  • Les tailles de tables définissent des conditions d’essai ; l’annexe B présente séparément des mesures sur BIRD/Linux, pas une vitesse valable pour les autres routeurs. Une valeur commerciale sans événements de départ et d’arrivée, charge et dispersion des essais ne permet pas de comparer deux routeurs.

Le paquet de mise à jour part du cache, mais l’usager n’a encore rien gagné. Le routeur doit recevoir les données RPKI, construire son état local de VRP, revoir les chemins BGP concernés et inscrire le résultat dans sa table de transfert. Ce dernier événement est celui qui change effectivement le chemin des paquets. Placer le départ du chronomètre à l’installation des VRP revient à omettre le trajet précédent, même si le rapport conserve le mot « convergence ».

RFC 8210 décrit le protocole RPKI-to-Router qui transmet ces données depuis le cache. RFC 6811 définit les états Valid, Invalid et NotFound pour l’origine d’une route BGP ; la politique qui utilise cet état reste locale. Une classification nouvelle ne pousse pas, à elle seule, un paquet sur un autre lien. Le calcul, le choix de chemin et la programmation matérielle suivent. La différence entre ces étapes est précisément ce qu’une mesure unique et mal étiquetée efface.

Dans son scénario de convergence provoquée par les VRP, le projet de méthode fixe le premier départ à l’envoi par l’émulateur RTR du premier PDU de mise à jour pertinent. L’arrivée exige un RIB BGP et un FIB stabilisés. Le second départ survient quand l’équipement testé a terminé l’installation de la mise à jour VRP pertinente ; son arrivée est identique. Ces deux intervalles ne répondent pas à la même question. Le premier mesure la réaction totale visible après un changement des données. Le second isole le travail restant une fois les VRP installés.

La distinction a une conséquence contractuelle simple. Deux matériels peuvent atteindre un FIB stable au même instant après l’émission d’une mise à jour. Celui dont la mesure commence plus tard affichera un intervalle plus court. Aucun constructeur n’est accusé ici d’avoir publié un tel résultat ; c’est une propriété du calcul. Pour établir ce qui se passe sur un appareil donné, il faut les deux départs et le même point d’arrivée, horodatés au cours du même essai.

Le projet décompose aussi l’installation des VRP : premier PDU envoyé, changement constaté dans la table locale, et, lorsque l’instrumentation le permet, premier et dernier VRP installés ainsi que durée globale du lot. Un autre test observe le changement d’état des préfixes BGP concernés. Dans le test complet, la sélection du meilleur chemin, un retrait ou un remplacement éventuel et la stabilité finale du RIB et du FIB entrent dans le dossier. Un fournisseur qui cite « la validation en millisecondes » peut donner une vraie mesure d’une seule de ces stations. L’acheteur doit savoir laquelle.

La charge rend les chiffres aussi fragiles que la ligne de départ. Le projet donne des exemples de tables à 50 000, 100 000, 500 000 et un million de VRP. Il évoque également un socle d’un million de routes IPv4 et de 250 000 routes IPv6, avec possibilité d’essais séparés par famille d’adresses si cela est indiqué. Ce sont des conditions proposées pour le laboratoire, pas un décompte du réseau mondial ni une mesure d’un produit. Le rapport doit montrer la population réellement chargée, la couverture des routes BGP, les recouvrements de VRP, la distribution des longueurs de préfixe et le nombre de routes dont l’état change.

L’annexe B apporte un contrôle concret. Sur son équipement de test BIRD 2.19.2/Linux, un ensemble initial de 1 060 368 VRP, 1 000 préfixes choisis et 1 230 opérations VRP donne, sur dix exécutions, 5 027,552 ms de convergence complète en moyenne contre 4 813,556 ms après installation. Les quelque 214 ms d’écart correspondent à la portion exclue par le départ tardif dans cet environnement ; la majeure partie du temps mesuré vient après l’installation. Aucun de ces chiffres ne classe un autre routeur. Ensemble, ils montrent pourquoi départ, charge et arrivée doivent accompagner le résultat.

La forme du lot compte. Des modifications concentrées dans une portion de la structure de validation ne sollicitent pas forcément la machine comme des modifications dispersées. Le projet demande les deux configurations. Il part d’un état RTR, VRP et BGP synchronisé, échauffe l’équipement, puis recommande de désactiver ou limiter la journalisation, la télémétrie en temps réel et des tâches de fond qui brouilleraient l’essai. Cette discipline favorise la répétabilité ; elle définit aussi la portée du chiffre.

Un réseau qui exploite ces fonctions doit tester sa propre configuration avant de transformer le résultat de laboratoire en objectif d’exploitation.

Le projet ne publie ni vainqueur ni panne constatée. Il met seulement une graduation sur une confusion commode. Pour décider de la capacité ROV, le nombre directeur part de l’envoi RTR et s’arrête au FIB stable. L’intervalle après installation sert à localiser le temps perdu. Les deux doivent accompagner la charge qui les a produits.

Projet de benchmark ROV, révision 00 · RFC 8210 · RFC 6811