Dear Jon, others, On Mon, Apr 04, 2022 at 05:48:42PM -0400, Jon Lewis wrote:
On Mon, 4 Apr 2022, Kenneth Finnegan wrote:
While I agree that it might be politically entertaining to let this one blow up as a demonstration of how ARIN conducts business, this list of networks includes too many small networks who likely don't have a savy networking engineering team.
In my opinion, they are not acceptable collateral damage to demonstrate ARIN's lack of regard for the community in shutting this down without a transition plan for the RPSL objects, so as one of the admins for the ALTDB IRR database, I've taken it upon myself to create proxy registrations for all of these prefixes in ALTDB.
Like any proxy registration, asset owners are welcome to contact the maint POC, and if no response from them, db-admin@altdb.net, requesting that stale records be deleted, but please also note that ALTDB automatically deletes any route objects which conflict with a publishes RPKI ROA, so the most effective way to clean up stale IRR records is to publish RPKI ROAs for your address space.
Does any other IRR do that?
An event not too dissimilar to the current situation at hand was when the server systems on which the "SAVVIS" IRR database existed experienced a catastrophic failure. At that time, Savvis had already been acquired by another entity, but they were unable to integrate/migrate dataset in time, and no backups appeared to be available. After some delibration and attempts to untangle the spaghetti of potential consequences for the BGP customer cone of my then-employer, I took the liberty to copy (proxy register) a significant number of route+route6 objects into NTTCOM (similar to what Kenneth did) because the alternative seemed worse. Deprecation of IRR databases is something very few people in this industry really have hands-on experience with.
What does ALTDB do if a route object exists (or multiple route objects exist for the same route with different origins) and multiple ROAs exist allowing the route to be originated by multiple ASNs? Technically, some of those ROAs would conflict with some route objects.
I can't speak with any authority on ALTDB operational matters, but I think they use a tool based on https://github.com/job/irr-nonauth-cleanup/ The 'irr-nonauth-cleanup' utility uses an algorithm similar to what is described in RFC 6811 in context of classifying BGP routes, and also is similar to what RIPE NCC uses to periodically clean up the "RIPE-NONAUTH" IRR database. RIPE NCC's cleanup effort was codified through community consensus and published as https://www.ripe.net/publications/docs/ripe-731 In the same spirit as RFC 6811 stipulates - RPKI ROAs never are considered "in conflict" with each other. As long as at least one ROA permits the specific (Prefix, Origin AS) tuple at hand to exist, the IRR object may exist. It's fine for multiple ROAs to exist which cover the same address space, this is what makes migrations/reconfigurations possible.
Are others jumping ship or planning to from ALTDB (no offense intended, and grateful for the service you've provided) and other non-auth IRRs like RADB due to networks like Tata announcing that they won't honor route objects created in non-authoratative IRR DBs after late last year and plan to ignore them entirely by late next year? i.e.
From: https://lg.as6453.net/doc/cust-routing-policy.html
Special note, deprecation of non-authoritative registries
Please note that 'route' and 'route6' objects created after 2021-Aug-15 in non-authoritative registries like RADB, NTTCOM, ALTDB and others will not work. Objects created before that date will continue to work till 2023-Aug-15. It is recommended to create RPKI ROA objects instead. In rare cases if that's not possible, 'route' and 'route6' must be created in the authoritative registry - AfriNIC, APNIC, ARIN, LACNIC, RIPE, RIPE, NIC.br or IDNIC.
I very much appreciate Tata's efforts to strive to only use authoritive data when making BGP routing decisions; however the scope of their charter is of course confined to just Tata's own operations. Tata's routing policies affect only Tata's customer cone. Depending on the exact characteristics of one's customer cone it may be feasible to only use RIR-provided IRR data sources, but it's not hard to imagine that for some providers this is a bridge too far at this point in time. Kind regards, Job