The RIPE 71 meeting held in Bucharest, Romania wrapped up last Friday, after a week of technical presentations, workshops, and plenary sessions in Internet number resource management and governance.
The policy discussion was quieter than more recent RIPE NCC meetings in part because the final /8 policy is now a baked-in process – there is less emotion around address management as a documented process.
Discussions on how to manage the small amount of necessary change had more flavour of “how” to do it, than what to say. For example, a substantive proposal was discussed to combine all transfer activity into a single document, so that transfers of Internet Number Resources (INR) was understood at a single point instead of distributed into an ASN, an IPv6 and an IPv4 instance. This isn’t aimed at making much change to how and when you can perform a transfer, but would make the logistics of negotiating transfer policy simpler.
RIPE NCC has a novel formal transfer policy for IPv6 when in many cases this isn’t held to be necessary. Merger and acquisition processes cover all INR, so having an explicit IPv6 transfer policy, when there is no shortage of IPv6, has been moot.
Discussing ASN policy
Discussions surrounding ASN policy were some of the more interesting during the meeting. This is because of two underlying issues.
First, we have come close to the end of the 16 bit ASNs, and so need policy to manage a graceful rundown of this scarcer resource against a far larger supply of 32 bit ASNs. By now the default is to give out a 32 bit ASN. But there remain times when people still have functional need of a 16 bit ASN – typically when they are going to engage in routing policy with community tags because they cannot easily be done globally in 32 bit ASN at this time. This exposes some of the routing dilemmas which confront ‘supply chain’ logistics. We have ASNs, but maybe not the right type for everyone’s needs.
Second, there are considerations about why you need an ASN. Some policy language goes directly to multihoming – being in the business of connecting to more than one upstream transit provider in BGP, and needing the ASN to present your own routing policy to both. Increasingly, people are single homed but still wish to use BGP to do routing engineering. This means that slight adjustments to ASN policy are needed to make it clear that any routing need in globally-visible BGP justifies an ASN.
Both issues are a lot more complicated and we wind up in process questions, more than content. If both changes are carried forward in one act, it invites dissent to one and not the other. This actually happened on the floor of the meeting with some voices calling for these changes to be handled separately.
But if the changes are “atomic”, then the document edit process is best understood to happen one at a time; and the whole process will take longer as each policy change is considered one at a time, on its merits.
These questions are being handled ably by the RIPE Address Policy Working Group chairs, as they negotiate the community sentiment at the meeting and on the list.
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.