The Path Forward - The Roadmap for ARIN’s New IRR

The Path Forward - The Roadmap for ARIN’s New IRR [Archived]

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.

After receiving multiple ARIN Consultation and Suggestion Process (ACSP) requests to update our existing Internet Routing Registry (IRR), we opened two community consultations last year to see if the community wanted us to take on the project of improving this service and what that would look like. The response was clear. The community would like us to:

  • Improve the validity of the IRR data

  • Work with the other Regional Internet Registries (RIRs) on authorization schemes

  • Provide appropriate proxy registration services

  • Integrate/validate with the registration database

To accomplish these goals, we anticipate a need to work closely with the other RIR communities, IETF, and operational groups such as NANOG, in order to create the appropriate incremental upgrades to the IRR.

Our Current IRR

We initially set up a RIPE-based IRR several years ago. Over the years, we have upgraded it based on ACSP suggestions. While these upgrades did allow for additional functionality, it came at a substantial cost of time and unanticipated functionality issues related to the upgrades.

Some of the issues found in our current IRR include:

  • The RIPE codebase was not modularized, with significant dependencies on RIPE’s environment, and which was not ideal for use in ARIN’s environment.

  • Adjusting to each upgrade from RIPE has been challenging because of innate differences in our database structures.

  • Our Registration Services Department has challenges providing customer support to IRR users. Common problems include: Maintainers not being notified upon changes, Cryptic responses to pgp-validation errors, General lack of customer support features.

  • It was our hope that code re-use would save time and money. Unfortunately, this was not the case, and the result was an awkward, difficult-to-operate, and user-unfriendly system that requires considerable engineering time to maintain.

It should also be noted that the IRR codebase in use by ARIN is no longer supported or maintained by the RIPE NCC, as they have since completely rewritten their IRR software.

Our Proposed Way Forward

Given the past experience with reusing code for IRR software, we propose a “ground-up” implementation of a validated IRR that will better integrate with our current web portal, provisioning system, and other registry functions. This path forward will be a multi-phased approach and will rely on community–defined specifications and global RIR community consensus.

By incrementally introducing a routing registry, we will be able to provide utility to the community much sooner and provide the community an opportunity to give feedback on the features and cost as the project progresses.

We do feel that this effort, once deployed, will help improve the routing coordination that exists on the Internet today. The proposed new ARIN IRR will provide a clear and consistent path to allow ISPs to share their routing policies.

View the full document that contains the proposed changes for the new ARIN IRR.

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.