Summary

  • LACNIC’s 27 May 2026 study says it considered all updates corresponding to March 2026 from RIPE NCC collectors RRC15 and RRC24, then says Python processing consolidated more than 2.222 billion BGP messages over a 48-hour period.
  • Its stability table reports exactly 2,222,981,835 BGP messages. Its IPv4 and IPv6 table reports 159,964,848 and 693,016,987 updates, a sum of 852,981,835 and therefore 1,370,000,000 below the message total.
  • Two other joins reconcile exactly: the IPv4 and IPv6 prefix counts sum to 1,436,539, and the four ASN behaviour categories sum to 86,398. The unmatched join may reflect a scope, message-type or processing distinction, not an error.
  • LACNIC should publish a versioned reconciliation receipt connecting exact time windows, collector peers, MRT files, parsing rules, intermediate counts and final tables. It should preserve uncertainty and avoid turning a routing observation into a regional census or an accusation against operators.

The arithmetic is a question, not a verdict

Reproducibility often begins with the least dramatic operation available: addition. In LACNIC’s article “Those Annoying Noisy BGP Speakers,” two such operations behave exactly as a reader expects. The address-family table lists 1,146,937 IPv4 prefixes and 289,602 IPv6 prefixes. Together they make 1,436,539, the unique-prefix total printed in the stability table. The population table assigns 43,199 autonomous systems to “stable,” 41,650 to “restless,” 1,530 to “noisy” and 19 to “critical.” Together they make 86,398, the published unique-ASN total.

The third operation does not close. The address-family table gives 159,964,848 IPv4 updates and 693,016,987 IPv6 updates. Their sum is 852,981,835. The stability table, however, gives 2,222,981,835 as the total number of BGP messages. Subtract one from the other and the gap is exactly 1,370,000,000.

The tempting headline would call this a billion-message error. That would be unjustified. The first label is “BGP messages”; the second is “updates.” One could be a raw count and the other a post-filter count. One might include message or MRT record classes that the other omits. The units could differ because one UPDATE can carry several prefixes, because withdrawals are handled separately, or because family attribution occurs after parsing. The public article does not supply the transformation needed to choose among these explanations.

That is the finding: not a false total, but a missing join.

The time window has the same unresolved join

The method description names two observation points: RRC24 in Montevideo and RRC15 in São Paulo. It says the study took “all updates corresponding to the month of March 2026.” The next paragraph names Python 3, mrtparser, pandas, NumPy and Matplotlib, and says the workflow consolidated more than 2.222 billion BGP messages “over a 48-hour period.”

There are several benign readings. Forty-eight hours might be the elapsed processing time. It might mean two selected observation days. It might represent one day from each collector, or a rolling interval inside March. “All updates corresponding to the month” might describe the archive searched rather than the records retained. The English, Spanish and Portuguese editions do not resolve the ambiguity.

Time is not decorative metadata in routing research. A month includes weekdays, weekends, maintenance, incidents and changes in peer availability. A two-day sample may still be excellent for finding extreme churn, but it supports a different claim from a complete-month census. Processing duration is different again: it says something about computation, not the network observed. A reproducible study needs a separate observation clock and processing clock.

The distinction matters especially because the conclusion says 0.02% of speakers generate most of the instability. The table’s 19 “critical” ASNs do equal about 0.02% of 86,398. But the durability of that concentration depends on the cohort and interval: which peers were present, which files were accepted, and whether the same speakers remain extreme beyond the selected window. The article’s statistic is valuable evidence inside its sample. It is not, by itself, a timeless property of the Internet.

Raw availability is not the same as disclosed lineage

RIPE RIS makes an unusually strong public starting point available. Its documentation says data is stored per route collector, combining what that collector receives from its peers. Raw paths follow a predictable form: rrcXX/YYYY.MM/TYPE.YYYYMMDD.HHmm.gz. Routing-table dumps are ordinarily written every eight hours; update files every five minutes. The March 2026 directories for RRC15 and RRC24 visibly contain separately named bview and updates files at that cadence.

This does not make the LACNIC result automatically reproducible. A directory is a shelf, not a checkout receipt. A reader still needs to know which objects left the shelf, whether partial or corrupt files were rejected, whether collector or peer gaps were tolerated, and how bytes became records, updates, prefix occurrences and per-ASN churn.

The two collectors are not interchangeable windows. RIPE NCC identifies RRC15 with PTTMetro-SP in São Paulo. Its documentation describes RRC24 as a multihop collector, and the peering page labels it “LACNIC Multihop” in Montevideo. A collector aggregates observations from its own peer cohort. That is immensely useful, but it is not a census of LACNIC members, Latin American routers, traffic, customers, outages or harm.

A public result can therefore be both open-source-adjacent and irreproducible. Naming RIPE RIS lets an expert locate possible inputs. It does not bind the published number to a finite file list.

“Message” is not a self-defining unit

The protocol and archive specifications explain why vocabulary matters. RFC 4271 defines distinct BGP OPEN, UPDATE, KEEPALIVE and NOTIFICATION messages. RFC 6396 defines MRT record families including table dumps, BGP4MP messages and BGP4MP state changes. RIPE RIS Live also exposes peer-state metadata alongside relayed BGP messages.

None of that proves what LACNIC counted. It shows that the word “message” cannot carry the method by itself. A raw updates archive can contain records whose treatment depends on the parser and on the research question. An UPDATE may announce multiple prefixes with shared attributes, withdraw prefixes, carry multiprotocol reachability, or contain no item that survives a later filter. Counting raw encapsulated messages, accepted UPDATEs, prefix actions and (peer, prefix, ASN) observations will produce different legitimate totals.

The address-family assignment is another decision. Is an UPDATE counted once in each family it touches? Are IPv4 withdrawals and IPv6 announcements separated? How are empty updates handled? Does “unique prefix” mean a distinct NLRI string across both collectors and the entire interval, or a distinct observation per peer before deduplication? How is an origin ASN assigned to multi-origin routes, AS sets or malformed paths?

Those choices do not belong in a footnote because they determine the denominator. They also determine what the churn rate means. LACNIC says it calculated the rate from the number of updates and prefixes advertised by each ASN. To reproduce the mean, median and four classification bands, a reader needs the exact numerator, denominator, attribution rule and population after exclusions.

The publication already demonstrates what a good join looks like

The two reconciled totals deserve attention because they show that the article is capable of an auditable structure. The prefix subtotal reaches the headline prefix count. The four behaviour categories reach the population count. A reader can reproduce those joins with a calculator and then concentrate on interpretation.

That clarity disappears at the message/update boundary. It also disappears between March and 48 hours. A one-paragraph reconciliation could restore it. Perhaps the 2.223-billion figure is raw records, followed by a family filter that retains 853 million prefix-bearing updates. Perhaps the larger total covers the month and the family comparison covers a 48-hour analytic slice. Perhaps the time phrase describes computation rather than observation. Any of these would be a reasonable method if disclosed. Without the bridge, readers are forced to manufacture it.

The page’s reference list links RFC 4271. That establishes the protocol foundation, not the run lineage. It does not identify the exact RIS objects, code revision, parser version or rejected inputs. Those are properties of this analysis, so only the analyst can authoritatively publish them.

A reconciliation receipt can be compact

The needed artifact is not a data dump of every peer or a demand that LACNIC expose internal workstations. It is a stable, privacy-safe receipt for one analytical run.

Start with two clocks. Give the observation interval in UTC, inclusive/exclusive boundary rules and any sampling windows. Separately give processing start and end. If 48 hours was compute time, say so. If it was the data slice, name its dates. If “March” names the archive discovery range but not the retained sample, make that selection explicit.

Then bind the inputs. Publish a manifest of exact RRC15 and RRC24 MRT filenames, hashes and byte counts, or a signed manifest that resolves to them. Record the peer-cohort snapshot, without republishing confidential details, and identify collector or peer gaps. State whether bview files were used only for state initialization or entered any total.

Define the counting units. Distinguish MRT records, BGP messages, UPDATE messages, announcements, withdrawals, NLRI items, prefix occurrences and unique prefixes. State which message and record types survive each filter. Explain how address families, multiprotocol fields, empty updates, malformed records, duplicate observations, multi-origin routes and AS sets are treated.

Next publish intermediate counts. One row should begin with accepted raw records, another with parsed BGP messages, another with UPDATEs, then family-assigned updates or prefix actions, and finally the population used for churn. Every chart and table should point to one stage. The 2,222,981,835 and 852,981,835 totals would then be different only if the receipt says why.

Finally record software and correction identity: Python version, mrtparser and data-library versions, analysis revision, configuration hash, run identifier, publication version and any errata. A result may change when a parser bug is fixed or a peer gap is discovered. A correction history protects the old claim rather than silently overwriting it.

Precision protects the operators being measured

The study offers plausible causes of noisy behaviour: software faults, configuration mistakes, equipment trouble, power events or attacks. These are general possibilities, not findings about the 19 critical ASNs. A high count does not identify intent, local impact, customer harm or preventability. Even calling an ASN “critical” is a classification inside the authors’ chosen distribution, not a disciplinary verdict.

A lineage receipt makes that boundary harder to erase. It lets an operator ask whether its ASN was observed from one peer or many, during one short event or throughout the window, under which origin-attribution rule, and against which version of the distribution. It lets an independent researcher test whether the concentration persists when the interval or peer cohort changes. It lets LACNIC correct a transformation without inviting the claim that the whole study was invented.

The fair conclusion is therefore narrower than either praise or scandal. LACNIC has published a substantial measurement and an arresting concentration statistic. The public arithmetic contains two complete joins and one unexplained one. The next act of transparency is not another chart. It is the receipt that shows how the chart was made.

Sources