Summary

  • AFRINIC's deployment monitor documents a four-state BGP classification in its 18 August 2026 release: exact-prefix announcement, more-specific routes only, not routed, and no data.
  • Applying its public display code to the complete South Africa file inspected on 3 September gives 239 exact-prefix cases and 42 more-specific-only cases. Together they make 281 of 522 listed blocks, rounded to 54%.
  • The file records a 20 August build date but no BGP snapshot date. The calculation is a reconstruction from published inputs, not a new routing survey, address-weighted deployment rate or service-availability test.

There are two sorts of routing observation inside this 54%. One says the listed prefix itself appears in the routing data. The other says more-specific routes appear, without an announcement of that exact prefix. Adding them is straightforward. Deciding what the sum means takes more care.

AFRINIC's Africa IPv6 & DNSSEC Deployment Monitor has made that distinction easier to see. Its 18 August release notes describe an expansion from two BGP states to four. They also separate missing information from a record classified as not routed. That is a useful improvement: the absence of an observation should not masquerade as an observed negative.

The extra detail survives underneath a combined total. The question is not whether the addition is wrong, but which question the result answers.

Reconstructing the total

The complete South Africa data file retrieved on 3 September contains 522 unique prefix records: 451 with allocated status and 71 with assigned status. Calling them listed blocks avoids pretending they are all the same kind of allocation event.

The public country-page script supplies a reproducible classification. A record explicitly outside the BGP dataset becomes no data. Otherwise an exact announcement takes precedence; an announcement without the exact prefix becomes more-specific-only; the remainder is classified as not routed. Applied to this file, it produces four disjoint groups.

State under the monitor's rule Listed blocks
Exact prefix announced 239
More-specific routes only 42
Classified as not routed 241
Classified as no data 0

The headline calculation includes the first two groups: 239 plus 42 is 281; 281 divided by 522 rounds to 54%. The script's explanatory sentence then names the exact and more-specific components. It does not leave the composition entirely hidden.

Counting only the 239 exact announcements would produce about 46%. That would be a different metric, not a corrected version of the same service score. Every listed block has equal weight in either calculation, whatever its prefix length. Neither measures the share of addresses, organisations, customers or successful connections.

A different route is not necessarily a worse route

The label more-specific-only can sound like an incomplete deployment. Its technical meaning is narrower. RFC 4271, in its discussion of overlapping routes, calls a route more specific when its longer prefix describes a smaller destination set. The relationship says nothing by itself about whether the operator's design is adequate for a particular service.

For an illustrative example, the two aligned /33 halves of a /32 can describe the whole /32 without an announcement of the /32 itself. This is prefix arithmetic, not a finding about any of the 42 South African records. It shows why the missing aggregate alone cannot prove that the smaller routes leave an address-space gap.

The converse matters too. Seeing the exact prefix does not establish that every destination hosts a working device, that all observers accept the route or that an application responds. A count of more-specific routes does not disclose their union and overlap. Routing information and end-to-end service behaviour remain different observations.

It would therefore be wrong to label the 42 cases broken, unused or insecure from these inputs. The 241 negative classifications are also bounded by the monitor's dataset; they are not proof of absence from every possible routing view. Zero unknown cases describes this captured country file, not measurement completeness across Africa.

The date attached to the number

The release notes say the old method counted a block when any part appeared and that stricter measurement lowered the percentages. That is the site's account of a historical change. This review did not reconstruct the earlier release or compare its BGP inputs with the later set. It cannot quantify a before-and-after fall, let alone call one a deterioration in the network.

The captured file has a build date of 20 August 2026 and a null BGP snapshot date. The script explicitly distinguishes them: it attributes a snapshot date when one exists and otherwise states when the data was built. The 3 September retrieval date supplies neither missing measurement time nor evidence of fresh route observation.

The country page also separates domain services, end-user adoption, address space and BGP into different tabs. Those are complementary views, not interchangeable certificates of deployment. A route announcement has not tested a website, a mail service or a customer's connection on the reader's behalf.

The upgrade is most useful when its detail travels with the percentage. The combined number can summarise the presence of either routing signal. The two components invite a more precise investigation. Neither needs to become a league table of good and bad network designs to earn its place on the dashboard.