Résumé

  • L’article de LACNIC du 27 mai 2026 dit prendre toutes les mises à jour de mars 2026 observées par RRC15 et RRC24, puis décrit la consolidation de plus de 2,222 milliards de messages BGP sur une période de 48 heures.
  • Le tableau de stabilité donne 2 222 981 835 messages. Le tableau IPv4/IPv6 donne 159 964 848 et 693 016 987 mises à jour, soit 852 981 835 au total et un écart exact de 1 370 000 000.
  • Les sous-totaux de préfixes et les quatre catégories d’ASN se rapprochent, eux, parfaitement des totaux annoncés. L’écart restant peut venir d’un périmètre, d’un type de message ou d’une étape de traitement différente ; il ne prouve pas une erreur.
  • Un reçu versionné devrait relier fenêtres temporelles, pairs des collecteurs, fichiers MRT, versions logicielles, règles de comptage, étapes intermédiaires et tableaux publiés, sans transformer l’observation en recensement régional.

Trois additions et une méthode invisible

Une bonne publication quantitative permet au lecteur de refaire les opérations simples avant de discuter les conclusions. Le texte de LACNIC sur les « noisy BGP speakers » y parvient deux fois. Les 1 146 937 préfixes IPv4 et 289 602 préfixes IPv6 donnent exactement 1 436 539, le total de préfixes uniques. Les 43 199 ASN stables, 41 650 agités, 1 530 bruyants et 19 critiques donnent exactement 86 398, le nombre d’ASN uniques.

La troisième addition conduit ailleurs. Les lignes « nombre total de mises à jour » indiquent 159 964 848 pour IPv4 et 693 016 987 pour IPv6. Leur somme est 852 981 835. Le tableau précédent annonce 2 222 981 835 « messages BGP ». La distance entre les deux nombres est exactement 1 370 000 000.

Il serait séduisant d’appeler cela une faute de calcul. Ce serait aller au-delà des sources. « Message » n’est pas nécessairement synonyme de « mise à jour » dans la chaîne d’analyse. Un total peut compter les enregistrements bruts, l’autre les UPDATE conservés après filtrage ou les actions associées à un préfixe. Les retraits, les messages sans préfixe retenu, les familles d’adresses et la déduplication peuvent déplacer le compteur. Le problème public n’est donc pas le nombre lui-même, mais l’absence de phrase permettant de passer de l’un à l’autre.

Mars et quarante-huit heures ne désignent pas forcément la même horloge

Le passage consacré à la source des données nomme RRC24 à Montevideo et RRC15 à São Paulo. Il affirme considérer toutes les mises à jour correspondant au mois de mars 2026. Juste après, la description du traitement cite Python 3, mrtparser, pandas, NumPy et Matplotlib, puis parle de plus de 2,222 milliards de messages consolidés sur 48 heures.

Les 48 heures pourraient être le temps de calcul. Elles pourraient désigner deux jours d’observation, deux journées-collecteur ou une fenêtre particulière au sein du mois. Mars pourrait être le répertoire exploré plutôt que l’échantillon final. Les versions anglaise, espagnole et portugaise conservent la même ambiguïté.

Une fenêtre courte n’annule pas l’intérêt d’une étude. Elle peut suffire pour détecter des valeurs extrêmes. Mais elle ne répond pas à la même question qu’un mois entier, riche en opérations de maintenance, incidents et variations de pairs. Il faut donc publier séparément le temps observé et le temps nécessaire au traitement.

Cette séparation encadre également la formule selon laquelle 0,02 % des speakers produiraient l’essentiel de l’instabilité. Les 19 ASN critiques représentent bien environ 0,02 % des 86 398 ASN du tableau. Leur persistance dépend toutefois de la fenêtre, des observateurs et des règles d’attribution. Il s’agit d’une concentration dans l’échantillon défini par les auteurs, non d’une identité permanente attachée à ces réseaux.

Les archives publiques ne choisissent pas l’échantillon à la place de l’auteur

RIPE RIS facilite considérablement l’enquête. Sa documentation décrit une collecte par route collector et un rangement prévisible : rrcXX/YYYY.MM/TYPE.YYYYMMDD.HHmm.gz. Les dumps de table sont produits normalement toutes les huit heures et les fichiers d’updates toutes les cinq minutes. Les répertoires de mars 2026 pour RRC15 et RRC24 montrent bien des fichiers bview et updates distincts.

Mais un répertoire complet, même public, ne dit pas quels fichiers ont été ouverts par l’analyse. Il ne révèle pas les fichiers incomplets, les erreurs de lecture, les périodes écartées, le moment où la liste des pairs a changé, ni l’utilisation éventuelle des bview. La disponibilité des données est une condition de reproductibilité ; elle n’est pas le journal de l’exécution.

La position des collecteurs doit elle aussi rester bornée. RIPE NCC associe RRC15 à PTTMetro-SP, São Paulo, et présente RRC24 comme le collecteur multihop de LACNIC à Montevideo. Chaque collecteur réunit les annonces de son propre ensemble de pairs. Ce regard distribué est précieux. Il ne compte pas les membres de LACNIC, les routeurs de la région, le trafic, les clients ni les pannes.

L’unité « message » doit être construite

RFC 4271 distingue les messages BGP OPEN, UPDATE, KEEPALIVE et NOTIFICATION. RFC 6396 distingue notamment les dumps de table, les messages BGP4MP et les changements d’état BGP4MP. Le manuel de RIS Live expose aussi des informations de changement d’état des pairs. Ces documents ne disent pas ce que les auteurs ont retenu ; ils montrent pourquoi ce choix mérite une ligne explicite.

Un UPDATE peut contenir plusieurs préfixes partageant des attributs, annoncer certains préfixes et en retirer d’autres, ou transporter des informations multiprotocoles. Après décodage, le nombre de messages, de préfixes, d’actions et d’observations par pair ne coïncide pas nécessairement. Un enregistrement MRT de changement d’état peut être utile à l’explication d’un churn sans appartenir au compteur final d’UPDATE.

Le rattachement à IPv4 ou IPv6 demande aussi une règle. Compte-t-on une fois un message touchant deux familles ? Que devient un UPDATE dont aucun NLRI n’est conservé ? À quel ASN attribue-t-on une route multi-origin, un AS_SET ou un chemin malformé ? La définition du churn rate — mises à jour rapportées aux préfixes annoncés par ASN — dépend directement de ces décisions.

Le rapprochement peut tenir sur une page

Un reçu utile commencerait par deux intervalles UTC : observation et traitement. Il préciserait si les 48 heures sont une durée de calcul, un échantillon ou une combinaison de collecteurs. Il donnerait ensuite la liste exacte des fichiers MRT, leurs empreintes et leur taille, ainsi qu’un état agrégé des pairs et des lacunes. Il indiquerait si les dumps bview servent à initialiser un état ou contribuent à un total.

La partie centrale définirait les unités : enregistrement MRT accepté, message BGP décodé, UPDATE, annonce, retrait, élément NLRI, occurrence de préfixe et préfixe unique. Chaque filtre aurait un compteur avant et après. Les règles IPv4/IPv6, les doublons, les messages vides, les erreurs de parsing, les routes multi-origin et l’attribution à l’ASN seraient versionnées.

Le tableau final ferait le rapprochement : entrées brutes, messages parsés, UPDATE retenus, actions par famille, population utilisée pour le churn, puis chiffre de chaque figure. Si 2 222 981 835 et 852 981 835 sont deux univers différents, le reçu le dirait sans demander au lecteur de le deviner.

Il faut enfin une identité logicielle : version de Python, mrtparser et bibliothèques, révision du code, empreinte de configuration, identifiant d’exécution et historique des corrections. Une réanalyse peut évoluer sans effacer l’ancien résultat. C’est précisément le rôle d’une version.

Ne pas transformer une classe statistique en accusation

L’article énumère des causes possibles de bruit : bogues, mauvaises configurations, problèmes matériels, alimentation ou attaques. Il ne démontre pas que l’une d’elles explique les 19 ASN critiques. Une observation élevée ne révèle ni l’intention, ni l’impact utilisateur, ni la responsabilité opérationnelle.

Le reçu protège donc aussi les réseaux observés. Il permet de distinguer un événement bref d’un comportement durable, un seul pair de plusieurs points d’observation, un changement du réseau d’un changement du collecteur. Il autorise une correction méthodologique sans convertir celle-ci en aveu de fraude.

La conclusion raisonnable reste précise. LACNIC a publié une étude importante et deux rapprochements arithmétiques impeccables. Le troisième n’est pas expliqué. Ce qui manque n’est pas un chiffre supplémentaire, mais la provenance qui relie les chiffres déjà là.

Sources