Summary

  • Breizh-IX says it regenerates strict prefix lists nightly, rejects prefixes lacking route objects, checks RPKI and respects PeeringDB's “Never via route servers” field. Its RS-API talk at RIPE 93 identifies a third question beyond registry membership and plausible route counts: does the customer want its route reannounced?
  • PeeringDB describes that field as a hint an exchange must fetch and honor. The exchange's own policy execution, not the presence of a checkbox in a database, determines whether the choice reaches the route server.

Three green lights, three different people holding the switches

An AS-SET can list the network behind an announcement. A route object can support the expected prefix and origin. Neither tells a route server that its customer wants the announcement sent to other exchange members. Those are distinct questions with different authors. A registry record is an operator's declared routing data. A volume limit is an exchange's risk decision. Permission to redistribute is the member's choice about its own peering.

That separation is the heart of the RS-API proposal by Evann Dreumont and Alarig Le Lay of Breizh-IX, scheduled for 28 October at RIPE 93. Their abstract lists three checks: look in the IRR for membership in the customer's AS-SET; ask whether the number of announced routes is coherent, especially when one nested set can import a vast routing table; and ask whether the customer wants to be reannounced through the route server. The first two are attractive to software because they look like lookup and arithmetic. The third is a decision by a participant whose route may be carried to peers it did not configure one by one.

The stakes are practical rather than metaphysical. RFC 7947 defines the exchange route server as an intermediate broker for multilateral BGP interconnection. A member connects to the broker instead of maintaining a separate bilateral session for every peer. That economy is why a policy error at the broker matters: one mistaken inclusion or omission can be repeated across the members to whom the server exports a route. The RFC describes per-client policy control; it does not turn an IRR record into a member's consent to every export.

The checkbox needs a reader, a clock and an operator

Breizh-IX's own site is unusually concrete about what its servers do today. The volunteer-run nonprofit says it rebuilds prefix lists nightly with bgpq4 in strict mode: without a route object, a prefix is rejected. It says its route servers check RIR RPKI ROAs and the OTC attribute, its second server checks ASPA records, and it respects PeeringDB's “Never via route servers” field. These are operator statements about current controls, not a measured audit of every announcement.

PeeringDB's own FAQ gives the field a narrower and more revealing status. The API calls it info_never_via_route_servers. PeeringDB calls the setting a hint to exchanges and tells networks to make sure their exchanges regularly fetch, evaluate and honor it. The database can record the choice. It cannot reach into an exchange's configuration to execute it. That is the distance between a preference visible on a profile and a policy applied to a BGP update.

The distinction creates a time problem. The member may change the flag after a route server's last policy refresh. The exchange may rebuild an IRR-derived prefix list overnight but obtain the PeeringDB choice on another schedule. An operator may also need to distinguish a deliberate change from a stale self-reported profile. None of these conditions is documented as an incident at Breizh-IX. They are the ordinary states a reliable consent path must expose: when the member changed the choice, when the exchange fetched it, which configuration received it and what the server actually did.

A nightly prefix-list job answers only one of those timestamps.

There is a second boundary inside the abstract's route-count test. A customer can supply an AS-SET that recursively names far more networks than the exchange expected. A generated filter can be syntactically correct while swallowing the entire default-free zone through a nested set. A maximum-prefix number entered in a profile is still a number someone chose. The proposed RS-API tries to make these records and the route feed confront each other at scale. The public abstract describes the design problem and the proposed proxy; it supplies no adoption count, error-rate measurement or released implementation to judge.

The operator's published current controls are firmer evidence than any imagined performance of the new tool.

The useful receipt is a decision trace

The exchange needs a compact answer for each customer and each policy generation: which AS-SET and route objects were consulted, which expansion produced the prefix list, what count threshold applied, what the PeeringDB flag said at fetch time, and which outbound peers were eligible to receive the route. The receipt should mark its source timestamps and the operator action that turned the inputs into running policy. A rejected route then has an intelligible reason; an accepted route has a traceable authorization path.

That is a governance decision disguised as a configuration detail. If the server silently treats an empty or stale field as permission, the exchange has chosen a default on the customer's behalf. If it silently treats the same field as a veto, it may cut useful reachability. The public evidence does not specify Breizh-IX's fallback rule for an unavailable or conflicting consent signal. A documented default, and a dated record of how it was applied, would change the assessment. Until then, a filter that parses cleanly says very little about who authorized the forwarding choice.

Sources