ELSOUL LABO B.V. dans le registre RIPE : que peut réellement prouver AS200261 sur un service à faible latence ?

Résumé

Le RIPE NCC répertorie ELSOUL LABO B.V. comme membre aux Pays-Bas. Son registre contient aussi un objet aut-num pour AS200261, nommé ELSOUL-LABO et marqué comme attribué. Ces éléments établissent une identité administrative et de routage publique, pas le trajet de chaque requête ERPC.
Dans la capture datée utilisée ici, RIPEstat indiquait qu’AS200261 était annoncé et observait un préfixe IPv4, 185.238.166.0/24. Les vues des collecteurs RIPE RIS contenaient des chemins se terminant par AS200261. Il s’agit d’observations limitées dans le temps et par la couverture des collecteurs.
Une requête RPKI distincte renvoyait l’état Valid pour AS200261 et ce /24, avec une autorisation correspondant à la longueur 24. Ce résultat confirme le couple préfixe-origine observé ; il ne valide pas tout le chemin, un produit, la disponibilité ou la latence.
La base RIPE présentait aussi, pour le même /24, des objets de route nommant AS200261, AS395201 et AS44486. Ces objets expriment une intention publiée. Ils ne démontrent pas que les trois origines sont actives en même temps.
ELSOUL affirme exploiter AS200261, des nœuds centraux ERPC et des validateurs, tandis qu’ERPC acheminerait les requêtes par plus de 300 points de présence périphériques. La société publie également une comparaison depuis Francfort. Ce sont des déclarations de l’émetteur, utiles mais non indépendantes.
Pour juger une promesse de faible latence, un acheteur doit mesurer la connexion, la réponse, le premier événement utile, la fraîcheur, les erreurs et les percentiles depuis ses propres régions. Le dossier de routage donne du contexte et de la responsabilité ; seul le test applicatif répond à la question du service acheté.

Fiche d’entreprise liée : ELSOUL LABO B.V.

L’image principale est une scène éditoriale photoréaliste originale montrant, de profil et sans identification, une personne comparant une vue abstraite de routes et un graphique de temps illisible dans un bureau ordinaire. Elle ne représente ni ELSOUL LABO B.V., ni ERPC, ni le RIPE NCC, ni Solana, ni une personne, un bureau, une installation, un réseau, une route, une mesure, un incident, une faiblesse, un résultat de service ou une approbation réels.

Une promesse simple qui mélange plusieurs systèmes

Une petite entreprise développe des alertes à partir d’événements publics d’une chaîne de blocs. Elle a besoin de requêtes RPC, d’une connexion WebSocket durable et d’un flux de nouveaux événements. Le fournisseur parle de faible latence, de proximité et de livraison en temps réel. Le client voit aussi un ASN propre à l’opérateur et suppose que l’essentiel du risque réseau a été résolu.

Quelques essais depuis Amsterdam répondent vite. L’équipe signe, puis des utilisateurs à Singapour signalent des alertes tardives pendant une période chargée. Les essais d’Amsterdam restent corrects. Une route demeure visible. Le service n’est pas nécessairement en panne et rien ne permet, dans cet exemple, d’accuser le fournisseur. Le problème est que l’achat reposait sur une question trop vague.

« Faible latence » peut désigner la résolution DNS, l’ouverture TCP, la négociation TLS, le trajet jusqu’à un point d’entrée, le transfert vers un cœur, le traitement de la passerelle, l’exécution par un nœud, la fraîcheur des données, la livraison d’un abonnement ou le code du client. Un bon résultat sur une seule horloge ne ferme pas les autres.

AS200261 concerne une partie de cette chaîne. Il fournit une identité dans le système de routage entre réseaux. Il peut rendre visibles une origine, une politique et des changements. Il ne révèle pas quel serveur a répondu, si une donnée était récente, combien de temps une file d’attente a retenu la demande ou si le client a reçu le premier événement utile à temps.

ELSOUL LABO B.V. constitue ici un objet d’entreprise précis. Les pages de l’entreprise décrivent ERPC et donnent des chiffres publiés par l’émetteur. Les registres et interfaces du RIPE NCC, complétés par les normes de l’IETF, permettent de contrôler le vocabulaire de routage. La valeur de l’analyse vient de leur rapprochement, à condition de ne pas transformer une preuve limitée en verdict global.

Ce que l’identité publique établit

La fiche membre du RIPE NCC place ELSOUL LABO B.V. aux Pays-Bas. Elle ancre un nom d’organisation dans le système régional qui coordonne des ressources numériques. Elle montre une relation administrative ; elle ne constitue ni une carte des produits ni un certificat de performance.

L’objet aut-num du registre RIPE est plus précis sur le plan du routage. La capture associe AS200261 au nom ELSOUL-LABO, à la référence d’organisation ORG-ELB1-RIPE et au statut ASSIGNED. Elle contient aussi des déclarations d’importation et d’exportation impliquant AS395201 et AS402175. Ce sont des éléments publiés de politique et d’identité.

On ne peut pas en déduire que tous les points d’entrée ERPC utilisent AS200261. Le registre ne donne pas la capacité d’un site, le taux d’erreur d’une méthode, le contrat d’un client, le niveau d’assistance ou la disponibilité d’un abonnement. Il ne dit pas non plus qu’un réseau observé aujourd’hui conservera exactement la même forme demain.

La société indique exploiter AS200261, des nœuds centraux ERPC et des validateurs Solana. Elle affirme également que le service passe par plus de 300 emplacements périphériques et cite Francfort comme site central. Ces descriptions sont celles de l’opérateur. Elles ne cartographient pas chaque point périphérique vers un préfixe ou un ASN, et elles ne prouvent pas que chaque requête reste dans un seul réseau autonome.

Un service mondial peut combiner DNS, entrée périphérique, transport d’un tiers, transit, liaison privée, proxy, passerelle et nœud applicatif. La présence d’un ASN propre peut améliorer la séparation et la responsabilité sur une portion. Elle ne permet pas de revendiquer le contrôle de toutes les portions sans preuve supplémentaire.

La conclusion sûre reste donc circonscrite : ELSOUL LABO B.V. possède une identité publique de membre RIPE, et AS200261 possède un objet public associé à cette organisation. Ces traces permettent d’étudier les ressources, l’intention de route, l’autorisation d’origine et les routes observées. Elles ne répondent pas seules à la question de la rapidité d’ERPC.

Un ASN expliqué sans jargon inutile

Internet rassemble de nombreux réseaux. Ils s’échangent des informations indiquant comment atteindre des blocs d’adresses. Un système autonome est un réseau, ou un ensemble coordonné de réseaux, qui présente une politique de routage aux autres. Son numéro, l’ASN, l’identifie dans ces échanges.

BGP, le Border Gateway Protocol, transporte les annonces de joignabilité entre systèmes autonomes. Une annonce associe un préfixe à un chemin. Chaque réseau applique ensuite ses propres règles pour accepter, filtrer ou préférer un trajet.

Un ASN peut donner à un opérateur plus de contrôle sur l’origine de ses préfixes et sur la façon dont sa politique est décrite. Il peut distinguer son identité de celle d’un hébergeur général et rendre une migration plus lisible. Il peut servir dans une architecture avec plusieurs fournisseurs, mais le numéro ne démontre pas que cette diversité existe réellement.

Une analogie raisonnable est celle d’un indicatif enregistré. L’indicatif dit quel domaine de routage parle. Une annonce indique qu’un chemin est proposé. Les observations externes montrent que certains témoins ont vu ce chemin. Aucune de ces informations ne mesure le délai nécessaire à une application pour produire une réponse correcte.

Le mot « propre » doit également rester précis. Exploiter son propre ASN ne signifie pas posséder chaque fibre, routeur, bâtiment, préfixe ou point périphérique. Des accords de transit, d’hébergement et de colocalisation peuvent intervenir. Les ressources d’adresses ont leur propre historique. Le client doit demander quel contrôle exact est exercé.

Quatre questions évitent la confusion : quelle organisation figure dans le registre ; quels préfixes l’AS est-il observé comme annonçant à une date donnée ; l’origine est-elle autorisée pour ces préfixes ; et l’application du client répond-elle correctement par le chemin effectivement reçu ? Les trois premières relèvent du réseau. La quatrième relève de l’expérience de service.

La photographie datée du routage

La réponse AS Overview de RIPEstat capturée pour cette étude identifiait la ressource 200261, associait le nom ELSOUL-LABO ELSOUL LABO B.V. et indiquait que l’AS était annoncé. C’est un état observé, pas une garantie continue.

La réponse Announced Prefixes donnait un seul préfixe sur la fenêtre de deux semaines terminée le 5 août 2026 à 16 h UTC : 185.238.166.0/24. Un /24 IPv4 contient 256 adresses. Cette taille ne révèle ni le nombre de services, ni celui des serveurs, ni celui des clients.

La réponse Routing Status présentait un /24 IPv4 d’origine, aucune ressource IPv6 d’origine dans cette vue et un voisin observé. Elle incluait des dates de première et de dernière observation. Le chiffre d’un voisin décrit ce que les données RIPE RIS voyaient alors. Il ne suffit pas à classer la redondance ou la diversité d’une architecture.

La réponse BGP State contenait de nombreuses vues de collecteurs pour le même préfixe. Les chemins se terminaient par AS200261, c’est-à-dire l’origine dans ces observations. Les AS précédents variaient selon les pairs et les collecteurs. Cette variété montre la portée de l’observation ; elle ne transforme pas RIPE RIS en carte exhaustive de chaque chemin Internet.

La documentation RIPEstat précise que BGP State repose sur les collecteurs RIS. L’identifiant de source aide à savoir quel pair a fourni une vue. Cette méthode est plus vérifiable qu’une capture d’écran isolée, mais sa couverture reste partielle. Une route absente d’un point de vue peut être visible ailleurs, et une route visible dans la capture peut changer ensuite.

La requête RPKI pour AS200261 et 185.238.166.0/24 renvoyait Valid. Le résultat comportait une autorisation correspondant à l’origine et à la longueur maximale 24. Autrement dit, pour la donnée du validateur à cet instant, le couple observé respectait une Route Origin Authorization couvrante.

Valid est une information importante de cohérence et de sécurité d’origine. Elle n’authentifie pas le chemin AS complet, n’identifie pas un produit, ne garantit pas que tous les réseaux acceptent l’annonce et ne mesure pas la réponse d’une passerelle. Il faut la lire comme une barrière précise, non comme un score de santé générale.

Trois objets de route ne font pas trois routes actives

La recherche dans le registre RIPE pour 185.238.166.0/24 a renvoyé des objets de route avec trois origines : AS200261, AS395201 et AS44486. La capture montrait une référence de mainteneur partagée et des dates de création au 30 mars 2026.

Un objet de route appartient à un Internet Routing Registry. Il publie une intention qui peut être utilisée pour préparer des filtres. Il n’est ni une annonce BGP vivante, ni un ROA cryptographique, ni un titre de propriété. Des objets multiples peuvent accompagner une transition, une organisation avec plusieurs opérateurs ou une intention conservée.

Il serait donc incorrect d’écrire que les trois AS annonçaient simultanément le préfixe. La vue BGP capturée doit répondre à la question de l’origine observée. La validation RPKI doit être demandée pour chaque combinaison destinée à être utilisée. Le registre conserve l’intention ; les collecteurs observent l’exécution ; le RPKI contrôle une autorisation d’origine.

Cette séparation révèle aussi une tâche humaine. Quelqu’un doit connaître l’état attendu, revoir les objets devenus inutiles, garder les accès de maintenance et expliquer la raison d’une pluralité d’origines. Sans propriétaire, un registre peut devenir exact sur le plan historique mais ambigu pour une opération urgente.

Ce que la route ne peut pas mesurer

La vue de routage ne contient pas le nom d’hôte utilisé par un client, la réponse DNS reçue, le point périphérique qui a accepté la connexion ou le nœud qui a fourni les données. Elle ne montre pas la négociation TLS, les contrôles d’accès, la file de la passerelle, le travail du backend ou l’âge du résultat.

Elle ne prouve pas la géographie du traitement. Une organisation enregistrée aux Pays-Bas, un site central annoncé à Francfort et une adresse visible sur Internet répondent à des questions différentes. La sélection d’entrée peut évoluer selon DNS et réseau. Un chemin peut traverser plusieurs opérateurs avant d’atteindre un cœur.

Elle ne prouve pas la capacité. BGP peut amener parfaitement des paquets vers une passerelle saturée. Une route peut être valide pendant que des abonnements attendent dans une file. Les routeurs ne connaissent ni le coût d’une méthode RPC ni la fraîcheur d’un état.

Elle ne prouve pas la continuité future. Une maintenance, une modification d’amont, une expiration d’autorisation ou une erreur de compte peut changer l’état. La continuité dépend autant des responsables, des accès et du retour arrière que de la configuration courante.

Enfin, elle ne définit pas « faible latence ». Une médiane à Francfort pour getSlot ne décrit pas le 95e percentile d’un abonnement à Singapour. L’ouverture d’un WebSocket ne mesure pas l’arrivée du premier événement. Une réponse rapide peut être ancienne. La mesure doit nommer l’événement de départ, l’événement d’arrivée et les conditions.

Six horloges dans une requête

La première horloge couvre le nom et la connexion : DNS, choix IPv4 ou IPv6, transport et TLS. Le cache, la perte de paquets et la distance y contribuent.

La deuxième couvre le trajet jusqu’au point d’entrée. BGP et les politiques des fournisseurs l’influencent, mais un chemin comportant moins d’AS n’est pas automatiquement plus court physiquement. L’ingénierie interne et la congestion restent invisibles dans une simple liste d’AS.

La troisième est le traitement périphérique : authentification, limitation, choix d’un backend, transformation ou inspection. Sur un chemin réseau court, cette étape peut devenir dominante.

La quatrième est l’exécution en arrière-plan. Une méthode peut lire un cache, attendre un nœud ou effectuer davantage de travail. Deux appels vers le même domaine n’ont donc pas la même courbe.

La cinquième est la fraîcheur. Une réponse peut arriver vite avec un état plus ancien. Dans un système en temps réel, le retard des données peut compter davantage que le temps de transport.

La sixième est l’application du client : connexions réutilisées ou non, reprises, file locale, décodage et actions en aval. Le fournisseur ne contrôle pas tout, mais le résultat d’affaires inclut ces éléments.

Pour un flux, il faut encore séparer ouverture, première notification utile, continuité, lacunes et retard soutenu. Un chiffre unique masque les échecs rares mais coûteux. L’ASN fournit du contexte à une partie du trajet ; il ne fusionne pas ces horloges.

Comment lire la comparaison publiée par ELSOUL

Le 11 mai 2026, ELSOUL a publié un article sur une évolution de l’infrastructure ERPC et une comparaison réalisée depuis le même environnement client à Francfort avec un important service RPC externe non nommé. Le texte cite HTTP getSlot, connexion WebSocket, première notification, fraîcheur des slots et erreurs.

L’émetteur rapporte une médiane de 23,4 ms pour getSlot sur ERPC contre 39,9 ms pour le service comparé. Il indique 87 ms contre 157 ms pour la connexion WebSocket, puis 240 ms contre 556 ms pour la première notification. Il affirme que la fraîcheur des slots était identique dans les contrôles et qu’aucune erreur n’a été enregistrée.

Ces chiffres ont une valeur documentaire : le lieu client et plusieurs métriques sont nommés. Le texte de l’entreprise reconnaît lui-même que les résultats varient selon la région, l’emplacement du client, les conditions d’abonnement, la méthode, l’heure, la charge et la configuration du backend. Il recommande des essais proches de l’usage réel.

Les limites demeurent. La source vient de l’entreprise. Le concurrent n’est pas identifié. La page ne fournit pas, dans le dossier public examiné ici, un ensemble brut complet, la durée totale, tout le profil de concurrence ou un observateur indépendant. Les résultats ne deviennent donc pas une propriété universelle du service.

La bonne utilisation consiste à reprendre les catégories de mesure et à les appliquer au besoin du client. Une équipe peut ajouter ses régions, ses méthodes, ses percentiles, sa charge, ses fenêtres et ses règles d’erreur. La publication réduit le coût de conception de l’essai ; elle ne remplace pas l’essai.

Un plan de mesure praticable

Commencer par l’événement d’affaires. Définir par exemple le temps entre l’envoi d’une requête précise et la réception d’une réponse valide, ou entre l’ouverture d’un abonnement et la première notification fraîche. Une phrase comme « l’alerte doit être rapide » ne peut pas être testée.

Choisir les emplacements où les utilisateurs ou les calculs fonctionnent. Si Amsterdam, Singapour et la Virginie comptent, les trois doivent apparaître. Noter la région cloud ou le fournisseur d’accès, car le point de départ influence le trajet.

Figer l’identité de la cible : nom d’hôte, adresses résolues, famille d’adresses, classe d’offre et méthode. Les secrets et les points d’accès privés ne doivent pas être publiés. Une offre partagée et une offre dédiée doivent rester séparées.

Décrire la charge : taille de demande, concurrence, réutilisation des connexions, délai d’abandon, nombre d’abonnements et durée. Mesurer médiane, 95e et 99e percentiles lorsque l’échantillon le permet. Compter les erreurs et expirations à part au lieu de les supprimer de la moyenne.

Mesurer la fraîcheur en parallèle. Comparer l’état ou le slot observé au même moment et avec le même niveau d’engagement. Une réponse ancienne livrée rapidement ne satisfait pas un besoin temps réel.

Ajouter un contexte réseau : réponses DNS, adresse de destination, observation BGP ou RPKI datée, et traceroute limitée lorsque cela aide. Ne pas attribuer un proxy ou un chemin privé à AS200261 sans preuve.

Répéter sur plusieurs périodes. Cinq requêtes vérifient que quelque chose fonctionne ; elles ne suffisent pas à acheter une garantie. La charge doit rester conforme aux conditions du fournisseur et ne pas devenir un test destructif.

Utiliser un contrôle : fournisseur actuel, autre service ou référence acceptée, depuis le même client et sous les mêmes conditions. La conclusion finale doit être bornée : lieux, méthodes, fenêtres, percentiles, fraîcheur et erreurs. Elle ne doit jamais devenir « cet ASN est rapide partout ».

Où RIPE Atlas aide, et où il s’arrête

RIPE Atlas fournit un réseau de mesures publiques et des interfaces documentées. Le guide de création sépare la définition du test, le choix des sondes et le temps. Cette discipline convient au contrôle de la couche réseau.

L’interface de statistiques ping décrit, par sonde, les paquets envoyés et reçus ainsi que le cinquième percentile, la médiane et le 95e percentile du temps aller-retour. Ces données peuvent révéler une différence régionale ou une variation du trajet mieux qu’un seul ordinateur de bureau.

Un traceroute peut compléter l’observation lors d’une transition. Il ne donne pas toujours une géographie certaine et certains routeurs répondent différemment aux sondes. Un ping ICMP n’est pas une requête RPC ; un traceroute n’est pas un abonnement WebSocket ; une sonde publique n’est pas forcément située dans le réseau exact du client.

Atlas renforce donc la partie réseau sans reproduire automatiquement l’application. Si le temps réseau reste stable et que la première notification ralentit, il faut regarder la passerelle, le backend, les files ou la fraîcheur. Si le réseau et l’application changent ensemble dans une région, le trajet mérite davantage d’attention.

Les coûts déplacés par la mesure et le contrôle

Un ASN plus autonome peut réduire une dépendance et rendre une politique plus explicite. Il crée aussi du travail : comptes de registre, contacts, objets de route, ROA, relations d’amont, surveillance, clés, changements et restauration. Le gain n’est réel que si ces contrôles ont des responsables.

La mesure applicative ajoute son propre coût. Il faut maintenir des clients de test, protéger des identifiants, choisir des régions, stocker les résultats, distinguer erreur et lenteur, vérifier la fraîcheur et réviser les seuils lorsque le produit change. Une équipe qui automatise les requêtes mais ne regarde jamais les écarts a seulement déplacé le travail vers une alarme sans propriétaire.

Les achats doivent aussi compter le chevauchement entre fournisseurs pendant une migration, les essais sous charge normale, le temps d’analyse des queues de distribution et le soutien d’une personne capable de comprendre BGP ou RPKI. Le prix mensuel d’un point d’accès n’est pas le coût total d’un résultat accepté.

La responsabilité doit être divisée sans devenir diffuse. Une personne possède l’exigence d’affaires, une autre la mesure applicative, une autre les observations réseau, et une personne coordonne la décision. En cas d’écart, l’équipe doit savoir si elle contacte son fournisseur d’accès, l’opérateur de la passerelle, le backend ou son propre développeur.

Échecs fréquents et conséquences concrètes

Traiter l’ASN comme un badge de performance mène à un achat sans preuve d’usage. Copier une comparaison de l’émetteur comme certification indépendante étend une expérience à des régions et méthodes non testées. Ne regarder que la moyenne cache les longues attentes et les erreurs.

Oublier la fraîcheur peut produire une réponse rapide mais inutilisable. Utiliser le ping comme test applicatif peut envoyer l’enquête vers l’opérateur réseau alors que la passerelle ou le backend est lent. Lire un objet de route comme une annonce active peut faire croire qu’une transition est terminée.

Interpréter Valid comme « sûr et disponible » ferme trop tôt l’analyse. Tester depuis un seul bureau transfère l’angle mort aux utilisateurs. Laisser les accès RIPE, RPKI, DNS et fournisseurs à une seule personne allonge la récupération lors d’un changement de personnel.

Publier des points d’accès, jetons ou détails de topologie expose des informations qui ne sont pas nécessaires à la conclusion. Un rapport public doit donner méthode, limites et résultat sans révéler de secrets.

Dans tous ces cas, le coût revient à des humains : triage, reprises, communication, double exploitation et décisions prises avec trop peu d’éléments. Une infrastructure visible n’élimine pas la supervision ; elle permet de mieux la placer.

Un programme de trente jours

Les cinq premiers jours servent à choisir quelques parcours sensibles. Définir départ, arrivée, fraîcheur, expiration, erreur et percentiles. Les jours six à dix servent à inventorier noms d’hôte, adresses, familles, régions et identité réseau réellement démontrable.

Les jours onze à quinze créent des essais reproductibles dans les régions utiles. La configuration peut être conservée, jamais les secrets dans un rapport public. Les jours seize à vingt ajoutent les observations RPKI, BGP et, si pertinent, les mesures Atlas.

Les jours vingt et un à vingt-cinq couvrent plusieurs fenêtres et la concurrence normale. Les résultats sont comparés à un contrôle. Les différences sont expliquées au lieu d’être absorbées dans une moyenne.

Les jours vingt-six à vingt-huit attribuent les réactions : origine inattendue, état RPKI invalide, variation régionale, perte réseau, passerelle lente, donnée ancienne ou erreur applicative. Chaque symptôme reçoit une première vérification et un propriétaire.

Les deux derniers jours produisent une décision datée. Le rapport dit ce qui satisfait le besoin, ce qui échoue, ce qui reste inconnu, qui peut agir et quand l’observation expire. Une autre personne doit pouvoir répéter la mesure.

Ce que les sources publiques n’établissent pas

Elles ne prouvent pas que tout le trafic ELSOUL ou ERPC utilise AS200261. Elles ne relient pas les plus de 300 emplacements décrits par l’émetteur à des préfixes, des AS ou des chemins de traitement précis.

Elles ne donnent pas le trajet d’un client particulier. Les vues RIPE RIS ne sont pas les chemins exacts depuis Amsterdam, Singapour ou la Virginie vers un point d’accès acheté.

Elles ne démontrent pas une diversité universelle. Un voisin observé n’est pas une carte complète, et une déclaration de politique ne garantit pas une relation active.

Elles ne reproduisent pas indépendamment la comparaison de performance. La page de l’entreprise donne un lieu et des chiffres, mais le service comparé reste non nommé et le jeu brut complet n’est pas fourni dans le corpus examiné.

Elles ne garantissent ni latence future, ni capacité, ni disponibilité, ni assistance, ni fraîcheur. Elles ne montrent pas non plus une panne, une faiblesse de sécurité, un client lésé ou un acte trompeur d’ELSOUL LABO B.V. ou d’ERPC.

L’état RPKI Valid ne protège pas le chemin complet. Les trois objets de route ne prouvent pas trois annonces simultanées. L’image reste un contexte éditorial, sans représentation de l’entreprise ou d’une mesure réelle.

Conclusion

La fiche membre d’ELSOUL LABO B.V. et l’objet aut-num d’AS200261 créent une identité de routage publique et vérifiable. La capture RIPEstat ajoute une vue bornée : un /24 IPv4 observé, des chemins se terminant à AS200261 et une validation RPKI Valid pour ce couple. La base RIPE ajoute une intention publiée avec plusieurs origines possibles.

Ces éléments comptent. Ils montrent une infrastructure plus concrète qu’une simple formule commerciale. Mais ils ne mesurent ni RPC, ni première notification, ni fraîcheur, ni erreurs. La publication d’ELSOUL fournit des chiffres attribués à un essai de Francfort et reconnaît elle-même les variations de région, méthode, charge et backend.

La règle utile pour une personne non spécialiste tient en quatre verbes : enregistrer, autoriser, observer et mesurer. Le registre dit qui est inscrit. Le RPKI dit quelle origine est autorisée. BGP montre ce que des collecteurs voient. L’application montre si des données correctes et fraîches arrivent à temps pour l’utilisateur.

Un ASN peut améliorer la responsabilité et le contrôle de route. La faible latence devient crédible seulement lorsque des mesures du service en fonctionnement confirment l’histoire du réseau dans des conditions définies. Le registre est un livre de comptes ; la route est un système en marche ; le résultat utilisateur est la réalité.