Summary

  • RIPE Labs’ third IRR Landscape article uses traffic measurements from AMS-IX and DE-CIX to test what parts of the IRR landscape RPKI can replace.
  • Its conclusion is asymmetric: third-party ROUTE(6) objects can largely be phased out in the studied scenarios, while third-party AS-SET objects remain essential for BGP filter generation.
  • The result does not authorize a universal IRR withdrawal. It separates a prefix–origin evidence role from customer-cone discovery, for which the study says ASPA is not yet broadly deployed.

Two route records can answer different questions

“IRR data” sounds like one thing until an operator asks what a particular object contributes. A ROUTE or ROUTE6 object can express a prefix–origin association. An AS-SET can be used to discover a set of autonomous systems behind a member and to construct a customer-cone view for filtering. Those are related components in a routing-policy toolchain, but they are not interchangeable statements.

The new RIPE Labs article makes that boundary concrete. It reports traffic-measurement work at AMS-IX and DE-CIX and compares production configuration with scenarios that reduce classes of third-party IRR data while incorporating RPKI-derived information. Its public conclusion is carefully divided: third-party ROUTE(6) objects can largely be phased out, but third-party AS-SET objects remain essential for BGP filter generation.

The word “largely” matters. The study does not announce that an IXP has removed data, that a particular network will remove it, or that every prefix–origin question is now settled by RPKI. It says ROAs can replace ROUTE and ROUTE6 objects where coverage exists. That condition preserves the difference between a tested scenario and an instruction for every routing policy on the Internet.

A ROA is not a customer cone

The other half of the conclusion is equally important. An AS-SET-based customer cone is not merely another spelling of a prefix–origin authorisation. It is used to discover a relationship set that can inform filter generation. The study identifies ASPA as the prospective operational replacement, while also saying it remains under standardisation and is not broadly deployed.

That is why the study should not be reduced to “RPKI replaces IRR.” It does not. It identifies one object class that can, in the tested conditions, be reduced without treating another object class as expendable. An accurate operating question is therefore not “Do we still use IRR?” but “Which IRR claim, from which source, serves which control today?”

The distinction also prevents a misleading security conclusion. A valid ROA is not evidence of a complete customer cone, bilateral routing policy, reachability or actual traffic. Conversely, an AS-SET’s continued use does not prove that all third-party ROUTE(6) objects are needed. The two layers require separate evidence and separate change decisions.

A withdrawal record should name the evidence being removed

An operator experimenting with reduced third-party IRR inputs needs a smaller and more useful record than a blanket “IRR off” announcement. It should identify the object class and source class being affected; the purpose that object served; the RPKI and authoritative-IRR coverage condition; the configuration scenario; the evaluation interval; any stated limitation; the observed scope; and the rollback trigger.

That record should also say what is deliberately retained. If third-party AS-SET material remains necessary for customer-cone discovery, a removal report that lists only discarded ROUTE(6) objects invites a false impression of total replacement. If an alternative uses RPKI-derived route objects, that is an implementation detail worth preserving, but it is not proof that an untested policy relationship has disappeared.

This is an editorial proposal, not a requirement imposed by RIPE NCC, AMS-IX or DE-CIX. Its purpose is to let a future reader recover the boundary the study preserves: one class of routing evidence may change role before another class can safely do so.

What the source does and does not establish

The RIPE Labs article establishes the study’s measured setting and its asymmetric conclusions about third-party ROUTE(6) and AS-SET objects. It does not establish a live deployment, a mandate, an incident, a particular operator’s route-filter state, or broad ASPA readiness.

Sources