At IETF 99, a “non-BoF” happened, following on from the CASM Birds-of-a-Feather (BoF) session held at IETF 98, Chicago.
CASM was a BoF about Coordinated Address Space Management: the need to understand how to deploy Internet Addresses into a large network, to optimize their use, and achieve beneficial routing outcomes. The proceeding “non-BoF” occurred because it was an off-agenda meeting organized by the CASM BoF co-chair Marc Blanchett. Around 20 people participated, mostly from the Chinese community, including staff from CNNIC and Huawei, but some consultants from data centres/exchanges were there, as well as staff from APNIC and the RIPE NCC.
I had committed to writing a draft for this meeting, which lays out the “problem statement” of what is currently available from the RIR system, and what might be useful to IPAM vendors. At this stage, it’s really just a list of the API choices available at each RIR (see below), and isn’t likely to form the basis of a working group activity. But it may lead to a working group if the need for work eventuates.
API choices available at each RIR
- Jordan Tay, (APNIC software development) presented on the emerging API specification APNIC has been doing during APRICOT 2017, Vietnam, earlier this year — it’s on our services roadmap as an area to explore.
- ARIN reports regularly on its own development efforts on JSON/REST mechanisms, which offer full service delivery to any ARIN member — it’s the same mechanisms that underpin their web interface.
- The RIPE NCC work is focussed on whois-based updates, which are a subset of member/registry interactions but include a wealth of functionality aimed at Internet Routing Registry (IRR) functions.
- LACNIC and AFRINIC have both expressed interest in an API, and it seems useful to consider this for future converged, cooperative service development.
CASM really has a narrow need from the RIR system — to provide a canonical list of “all resources” which can then be configured into the network.
But it’s possible to look inside RIR process and see other functions that might be useful to expose in a consistent API for an IPAM system to work with:
- mechanisms to register and maintain reverse-DNS
- mechanisms to modify routing registry
- mechanisms to enable RPKI and maintain Route Origin Authority (ROA) statements
At this stage, CASM is looking to define more abstract models of the data primitives, which might apply here, and is a long way from formalizing a protocol or interface specification facing upwards to the RIR. (In CASM parlance, this is called the “north” facing interface. “South” facing refers to applying it down to the network deployment inside the address holder’s network).
It’s likely that a YANG data model will eventuate and a small set of functions is defined facing RIR services, but not at this stage is there a specific mechanism worthy of being called a common API.
In fact, there is no clear sign CASM will become an adopted working group with a charter, although the commitment to write drafts from the people in the room is often a good sign it will go the distance. The interest in activity from those present was clear, and I don’t sense a decline in motivation.
APNIC continues to develop its systems in line with evidence of need and we’re still gathering information to understand how much IPAM systems can integrate, and in what manner we might support them. Our current work focusses on the design of JSON data models across a REST interface and since we have adopted the use of a simple two-factor authentication system for MyAPNIC, a future API may need this to be augmented by a ‘token’ mechanism enabling API functions in code, and which can be managed and withdrawn on demand by the resource holder in the MyAPNIC interface.
We see very similar systems from Amazon and Google for their cloud services, where you use the higher trust web interface to manage tokens, and which you can then download to use inside an application’s code.
So, at this stage, there is no clear signal to develop an APNIC API, but we’re keeping a watching brief on things, and will continue to engage with the community and IPAM vendors to explore needs in this space. If we get a clear signal people would like an API to perform address management functions, we’re ready to move.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.