[ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap

[Mark Kosters]

Hi Job

Thanks for volunteering to help :^). We'd certainly like to hear your
opinion on the plan. We are certainly open to any suggestions for
improvements that you may have. This goes to anyone else on the list as
well.

Thanks,
Mark

On 1/9/18, 4:52 PM, "ARIN-consult on behalf of Job Snijders"
<arin-consult-bounces at arin.net on behalf of job at ntt.net> wrote:

>Dear ARIN,
>
>Where do I sign up to help?
>
>Kind regards,
>
>Job
>
>On Tue, Jan 09, 2018 at 04:27:58PM -0500, ARIN wrote:
>> 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:
>> 
>>   *  Improve the validity of the IRR data
>>   *  Work with the other RIR's on authorization schemes
>>   *  Provide appropriate proxy registration services
>>   *  Integrate/validate with the registration database
>> 
>> 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.
>> 
>> We are opening a new Community Consultation to solicit feedback on the
>>ARIN
>> IRR Roadmap, detailed below.
>> 
>> Please provide comments to arin-consult at arin.net.
>> 
>> This consultation will remain open through 5:00 PM EST on Friday, 9
>>February
>> 2018.
>> 
>> Regards,
>> 
>> John Curran
>> President and CEO
>> American Registry for Internet Numbers (ARIN)
>> 
>> *ARIN IRR Roadmap**
>> **
>> **Background*
>> 
>> 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.
>> Within the consultation, the ARIN community was asked three questions:
>> 
>>     * Should ARIN begin a new project to enable IRR route object
>>validation
>> to the ARIN registry database?
>>     * If yes, should this effort be coordinated with other RIRs to help
>> facilitate cross-registry authentication?
>>     * If yes, should this effort also support third party IRR route
>>object
>> authentication?
>> 
>> 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.
>> 
>> 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.
>> 
>> Two participants suggested ARIN provide facilities for
>> authentication/authorization or delegation to IRRs not operated by an
>>RIR.
>> 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.
>> 
>> *Implementation Experience Regarding ARIN's Current IRR*
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> ARIN Registration Services Department also 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.
>> 
>> *Proposed Roadmap*
>> 
>> 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.
>> 
>> 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.
>> 
>>     * 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.
>>     * 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.
>> 
>>     * 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.
>> 
>>     * 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.
>> 
>>     * 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.
>> 
>>     * 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.
>> 
>> 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.
>_______________________________________________
>ARIN-Consult
>You are receiving this message because you are subscribed to the ARIN
>Consult Mailing
>List (ARIN-consult at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-consult Please contact the
>ARIN Member Services
>Help Desk at info at arin.net if you experience any issues.