Summary

  • RIPE NCC’s Q3 2026 plan says RIPEstat will add BGP community descriptions soon. The current Looking Glass API already exposes a community_info object and names the NLNOG Looking Glass project as a source of some known-community information.
  • A single frozen lookup for 193.0.20.0/23 returned 349 peer entries across 23 route-collector groups. Seventy-one entries contained non-empty community information; that is a description of this capture, not a platform-wide coverage rate.
  • In the response, the wire value 12859:4000 was described as “customer routes”, while the accompanying original field was 12859:4xxx. The annotation therefore came through a wildcard rule, not an exact textual identity.
  • A reliable display needs a compact description receipt: community type, observed value, matched expression, match class, description source, source version or hash, retrieval time, declared meaning, route observation time and whether the text is informational or requests an action. Even then, the description does not prove that an action occurred.

The route carried a number; the interface supplied a sentence

The Q3 2026 RIPEstat plan places BGP community descriptions among the next Looking Glass improvements. This is a sensible piece of interface work. A raw community such as 12859:4000 means little to a reader who does not already know the convention maintained by the relevant network. A short explanation can turn a table of tokens into an operational view.

But the sentence is not carried in the BGP update. The Looking Glass API reports the community attributes observed through RIPE RIS and then exposes community_info as additional information for regular and large communities. Its data-source page identifies the NLNOG Looking Glass project as the provider of some known-community information. The route observation and the human description therefore arrive through different evidence paths.

That distinction matters because the interface puts them next to each other. Adjacency is visually efficient, but it can make a derived annotation feel like a property measured from the route. What RIS observed is the community value on a route received from a peer. What the description layer adds is an interpretation selected by a matching process.

RIPE NCC’s 2025 launch note says the redesigned tool uses RIS, parses regular, large and extended communities, is available through the API and was released early for refinement. That is the right moment to preserve the seam. Once descriptions are copied into screenshots, incident notes and automation, the seam becomes harder to reconstruct.

One lookup exposes the matching problem

The evidence packet for this article froze one Looking Glass response for 193.0.20.0/23. It returned status ok, API version 2.1, a latest_time of 2026-09-14T20:20:43, 23 RRC groups and 349 peer entries. Seventy-one (71) peer entries had a non-empty community_info object.

Those counts describe only that response at that time. They do not estimate how often RIPEstat can explain communities, how complete NLNOG’s files are or how frequently operators document their policies. The query chose one RIPE NCC prefix and captured one moment. Its value is not statistical breadth; it is the evidence shape visible in a real response.

One peer entry contained 12859:4000 in its observed community string. Inside community_info.regular, the key was again 12859:4000, the description was “customer routes”, and the original expression was 12859:4xxx. Another entry retained an exact original value, 2914:410, beside the description “NTT and customer routes”. The API can therefore preserve an important distinction already: some annotations come from an exact expression, while others are instantiated from a broader pattern.

The problem is not that wildcard matching is inherently weak. A network may deliberately document a whole family of values with one stable rule. The problem is that the reader needs to know which kind of match produced the sentence. 12859:4000 = customer routes and 12859:4000 matched a rule for 12859:4xxx described as customer routes are not equivalent evidence statements.

The first looks like an exact dictionary entry. The second tells the truth about the inference. It also leaves room for a more specific rule, a conflict or a later correction.

A wildcard is part of provenance

The NLNOG Looking Glass repository documents two input paths for known communities. One retrieves formalised YANG-style descriptions from listed URLs. The older path uses one text file per ASN, with a community expression, a comma and a description on each accepted line.

The legacy matcher is intentionally practical. It accepts exact values, ranges, single-digit wildcards and arbitrary-number patterns. Captured wildcard values can be inserted into a description. This makes a compact file capable of explaining a large namespace without enumerating every value.

It also means the matched expression is evidence. An exact match can support a narrower claim than a range. A range can support a narrower claim than a pattern that accepts any suffix. None is automatically wrong; they simply have different resolution.

The repository welcomes additions and updates and asks contributors, where possible, to provide a source in a first-line comment. That wording is candid. It does not guarantee that every legacy row has an operator-controlled source, a revision date or a durable citation. The frozen community_urls.yml listed formalised feeds for AS25152 and AS197000. It was not a registry of all descriptions that appeared in the frozen RIPEstat response.

This does not prove that the 12859:4xxx rule is inaccurate. It proves something narrower: the response itself did not tell the reader which source record, source revision or retrieval event supported that description. The original match expression survived; the rest of the lineage did not travel with it.

A description has a different clock from the route

The Looking Glass endpoint is built from near-real-time RIS data. Its latest_time helps a user assess the recency of the routing observation. That clock does not date the description.

A description may have been retrieved earlier, copied from an operator page, submitted through a repository pull request or generated from a formal feed. The operator may later change the meaning of a value while an old route remains visible. Conversely, a description file may be updated while the route observation is unchanged. One timestamp cannot represent both histories.

The same separation applies to authority. RFC 1997 defines the regular BGP Communities attribute and permits an autonomous system to define the semantics of the locally administered part outside reserved ranges. RFC 8092 gives Large Communities a global-administrator field and two local data fields. The numeric structure helps identify the namespace. It does not authenticate a web description or prove that every receiving network interprets the value identically.

Communities are optional transitive attributes. Networks may add, remove, modify, propagate, ignore or act on them according to policy. A RIS collector can show what reached one peer. It cannot infer every policy evaluation that occurred before or after that observation.

Informational text and action requests need different verbs

RFC 8195 offers a useful editorial distinction. Informational Communities label properties such as where or how a route was learned. Action Communities request that a network perform a defined operation. Operators are encouraged to publish and maintain documentation for both.

The categories can overlap. An action community’s presence can also be informative because it records a request. But presence is not execution. A label asking a provider to prepend a path, suppress an announcement or change distribution does not prove that the receiving router accepted the request, that policy matched it, that the action propagated or that it remained in force.

This is why a Looking Glass should avoid a single unqualified verb such as “does”. For informational text, “documented as” is safer than “is” when provenance is indirect. For action text, “requests” is safer than “causes”. If the interface later has independent evidence of an observed outcome, that evidence should occupy a separate field with its own time and method.

The 12859:4000 example is informational wording, not an action claim. “Customer routes” still needs care: it describes the documented class attached to the community. It does not establish a contract, legal customer relationship, ownership or current commercial status for every prefix carrying the value.

The compact receipt

A useful description can stay concise while carrying an inspectable lineage. The visible row can show the observed value and plain-language description. An expandable receipt can carry the rest:

Receipt field What it prevents
Community type Confusing regular, large and extended structures
Observed value Losing the attribute actually present in the route record
Matched expression Presenting a wildcard or range as an exact definition
Match class Hiding whether the result came from exact, range or pattern matching
Description source Treating an aggregator, operator page and formal feed as equal authority
Source revision or content hash Silently changing the meaning attached to an old observation
Retrieved and valid-as-of times Collapsing description freshness into route freshness
Semantic class Mixing informational labels with action requests
Route observation time and RRC/peer Detaching the annotation from the routing evidence it explains
Conflict and supersession state Making corrections overwrite the history a prior decision used

The receipt need not certify correctness. It records what was matched, where the words came from and what kind of claim the words make. A user can then decide whether the description is sufficient for a dashboard, needs confirmation for an incident response or should be excluded from an automated policy decision.

The design should preserve absence too. “No description found” is different from “source unavailable”, “rule conflicted”, “description expired” and “community type unsupported”. Empty output without a reason encourages users to fill the gap from memory.

What the frozen response supports

The frozen response supports a limited and useful conclusion. RIPEstat exposed a real community value, a human description and the broader expression from which the description was matched. That is already more transparent than returning the sentence alone.

It does not support a claim that the description was wrong, that the route was unsafe, that a customer relationship existed, or that a policy action succeeded. It does not measure the global quality of NLNOG’s community catalogue. It does not imply misconduct by RIPE NCC, NLNOG or any ASN in the path.

The next improvement is therefore not a red warning. It is a provenance disclosure that travels with the useful text. RIPEstat plans to make opaque communities easier to read. Keeping the wildcard visible will make those explanations easier to trust without asking them to prove more than they can.

Sources