<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Over the last several years, ARIN has received multiple ARIN
Consultation and Suggestion Process (ACSP) requests and fielded
many customer suggestions about our existing Internet Routing
Registry (IRR), and as a result, a community consultation was
issued to gauge community interest for ARIN to take on the project
of improving this service. The consensus response was that the
community would like ARIN to:<br>
<br>
* Improve the validity of the IRR data<br>
* Work with the other RIR's on authorization schemes<br>
* Provide appropriate proxy registration services<br>
* Integrate/validate with the registration database<br>
<br>
To accomplish these goals, we anticipate that this work effort
will involve a fair bit of community involvement (RIR communities,
IETF, and operational forums such as NANOG and CaribNOG) in order
to create the appropriate incremental upgrades to the IRR.<br>
<br>
We are opening a new Community Consultation to solicit feedback on
the ARIN IRR Roadmap, detailed below.<br>
<br>
Please provide comments to <a class="moz-txt-link-abbreviated" href="mailto:arin-consult@arin.net">arin-consult@arin.net</a>. <br>
<br>
This consultation will remain open through 5:00 PM EST on Friday,
9 February 2018.<br>
<br>
Regards,<br>
<br>
John Curran<br>
President and CEO<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<b>ARIN IRR Roadmap</b><b><br>
</b><b><br>
</b><b>Background</b><br>
<br>
In response to multiple ACSPs regarding IRR route validation (i.e.
the function whereby route objects are validated via the
authorization of the appropriate number resource holder), ARIN
conducted an IRR community consultation in April 2015. This
consultation was opened because the issues around IRR route
validation are complex, and implementation was anticipated to
exceed the cost of most ACSP implementations.<br>
Within the consultation, the ARIN community was asked three
questions:<br>
<br>
* Should ARIN begin a new project to enable IRR route object
validation to the ARIN registry database?<br>
* If yes, should this effort be coordinated with other RIRs to
help facilitate cross-registry authentication?<br>
* If yes, should this effort also support third party IRR
route object authentication?<br>
<br>
There were eighteen individual participants in the consultation.
Thirteen were in favor of ARIN creating a more robust IRR, two
were publicly against, and three were unclear in their support or
opposition.<br>
<br>
Nine participants expressed support for efforts to facilitate
inter-RIR authentication, and eight participants expressed support
for 3rd party or proxy registrations for authentication of route
objects.<br>
<br>
Two participants suggested ARIN provide facilities for
authentication/authorization or delegation to IRRs not operated by
an RIR.<br>
Several participants had concerns regarding the implementation of
an ARIN-validated IRR. Three noted ARIN's past experience with the
implementation and cost of RPKI with respect to both community
adoption and opportunity-cost, and one participant expressed
concerns for contractual obligations that ARIN may place on
resource holders provisioning information in a validated IRR.<br>
<br>
<b>Implementation Experience Regarding ARIN's Current IRR</b><br>
<br>
ARIN initially setup a RIPE-based IRR years ago. Over the years,
we upgraded it based on ACSP suggestions: IPv6 support was
implemented in December 2009, and PGP support with additional
notifications was released in September 2011. In both of these
releases, we replicated the original approach of using the RIPE
database software system with loose coupling to our mainline ARIN
Online registry system. These upgrades did allow for additional
functionality, but it came at a very substantial cost of time and
unanticipated functionality issues related to the upgrades.<br>
<br>
When we undertook these upgrades, we chose to continue the
separation in the hopes of doing minimal environmental changes to
ARIN's infrastructure to add the suggested improvements. However,
the RIPE codebase was not modularized, with significant
dependencies on RIPE environment, and consequently was not ideal
for use in ARIN's environment. One consequence was the repeated
need to pull down the latest release from RIPE, adjust the
environment for their software to work, make changes to it to
allow functionality that we support, remove out dependencies to
resource checks that would not exist in our system, and add
dependency links to our system. This has been a very
labor-intensive process and it took a lot of engineering time to
make the system work.<br>
<br>
Adjusting to each upgrade from RIPE has also been challenging
because of innate differences our database structures. RIPE had
two systems – one being a front-end database and the other being a
back-end database with manual synchronization between these two
systems. At ARIN, we have just one system that is placed behind
the firewall and replicated out to the publically available ARIN
slaves as changes are made. The RIPE IRR codebase provided for
limited information to be shared to slaves via its replication
schemes. Given that ARIN's publically available interface is a
slave, the output available to our community was not the same as
our internal master, and has resulted in some confusion for ARIN
IRR users.<br>
<br>
ARIN Registration Services Department also has challenges
providing customer support to IRR users. Common problems include:<br>
<br>
* Maintainers not being notified upon changes<br>
* Cryptic responses to pgp-validation errors<br>
* General lack of customer support features<br>
<br>
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.<br>
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.<br>
<br>
<b>Proposed Roadmap</b><br>
<br>
Given the community feedback received in the consultation, and
with due regard to the past experience with reusing code for IRR
software, ARIN staff proposes a "ground-up" implementation of a
validated IRR that will better integrate with ARIN's 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.<br>
<br>
This approach will allow ARIN to field a routing registry
incrementally, providing utility to the community much sooner than
a monolithic "big-bang" release, and it will provide the community
an opportunity to provide feedback with respect to features and
cost as the project progresses.<br>
<br>
* Produce a Simplified Profile of RPSL: Most of the complexity
of RPSL comes from routing registry features rarely used by the
community. To reduce the implementation costs around data modeling
and parsing of complex RPSL structures, ARIN will work with the
operational community to identify the most commonly used features
of the language, and this subset will be documented as an
simplified RPSL profile to be used to guide development efforts.
<br>
* Schedule Frequent Deployments: ARIN will adopt "continuous
deployment" strategies to allow for more frequent deployments,
similar to the strategy used today in development of the ARIN
Online registry system. This will allow the community to use new
features of the IRR as they are developed.<br>
<br>
* Collaborate on Cross-RIR Authentication: ARIN will work with
the other RIRs engineering coordination activities to create an
appropriate mechanism for authentication and authorization of
routing registry objects for which the resources cross regional
boundaries.<br>
<br>
* Provide an Easy IRR integration tool within ARIN Online:
ARIN will provide an simple tool within ARIN online for those
users who wish to explore the routing of their existing number
resources and after successful review, automatically update their
corresponding IRR records to match existing routing.<br>
<br>
* Migrate Data to the New IRR: Where possible, ARIN will
create tools and practices to help migrate data from the existing
IRR to the new IRR under the authority of resource holders in the
ARIN registry.<br>
<br>
* Cooperate on Standards and Best Practices: Where applicable
and appropriate, ARIN will work with the IETF and the other RIRs
on documenting any resulting operational standards, profiles, and
best practices.<br>
<br>
We do feel that this effort, once deployed, will help improve
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.<br>
</p>
</body>
</html>