Archives RIPE 59 Lisbon, 5-9 October 2009

These are unedited transcripts and may contain errors.

��The Address Policy session commenced on the 7th of October, 2009, at 9 a.m. as follows: GERT DOERING: Good morning dear Working Group, or what is left of it. I am actually quite happy to see that a few of you have made it, but compared to yesterday's plenary, the rows a bit thin but maybe that means that everybody who is interested in Address Policy, is here and everybody who is just reading e mail is not. Definitely thanks for coming, it's 9:00 in the morning, it's after a big party. I will try to keep it going easy. As I said, this is the Address Policy Working Group. As a matter of introduction for people that are here for the first time, my name is Gert Doring, I am chairing this, I have a co chair, Sander Steffann, who is sitting up there in the first row. But there is some excitement in the room, which is good. As you are aware, this session is webcast so if you want to comment on anything, please use microphones so that people can hear you. And if you don't want to be archived, well, talk to us in private, also. But since this is all being open transcribed and so on, that is the way it is. This is the overall agenda of the things we will do today and tomorrow. We have three full time slots and quite a lot of stuff on the agenda. Well, basically, Address Policy being Address Policy, it's the same things that we do every time; report on the current status of policy things, report on ongoing policy things, discuss open policy proposals. But we have a few new things and I will go through the agenda in a bit more detail now. This is what we start with today, administrative matters, agenda bashing, thanking the scribe and not Ingrid from the RIPE NCC is taking notes, and this is a hard job, so thank you very much, so please give her an applause. (Applause) Thank you, it is really not an easy job. Then we will approve the minutes right after the agenda bashing. Then we have the traditional report from Filiz from the RIPE NCC about the current policy topics in the RIPE region and in other regions, to just get you informed what is going on and give you background information to make better educated decisions. Then, we have something new. In the last few years, policy making has been sort of like the the Working Group does policy. We put the policy that we have made on the desk of the RIPE NCC and the IP resource analysts have to implement it. We are not really the people affected by the policy because we are just, say, a few hundreds and there are 6,000 LIRs out there that are directly affected by the policy we make. So if we make a policy that makes 5,000 LIRs unhappy, we might not actually know. So, this is why I ask the NCC, the registration services department, to give us feedback on things that they have seen in day to day operations where our policies are a bit vague, a bit unclear, things that need to always the same discussion again and again and again so that might point to a problem in the policies, so we will have some feedback from the people that actually live these policies day by day and then we can decide whether we need or want to change anything. After that, I will give a short update on the routing issues discussion that we had last meeting. Then, it's Filiz again. You remember there was this document cosmetic surgeries project announced at the last meeting which had the goal of making these sometimes very stitched together policy documents more readable without changing their actual meaning and some progress has been made and Filiz will tell you what the current state of affairs is. Then it's time for the coffee break. And then we go into the actual discussions, a short report on what happened with new proposals since RIPE 58, discussion of all the open policy proposals that you can see listed there, and then discussion of the last /8. There is two proposals on the table which are sort of incompatible. There has been some legal advice to the NCC on things that we should do or should not do regarding monopoly things and EU law and so on. Since this resource is running out, it might be prudent to actively check that we are on a safe track. This is tomorrow. Tomorrow, we will have again something new. Dr. Welbrink from the German Ministry of Defence asked me for a time slot to present a bit on their problems with the current IPv6 Address Policy and the military requirements, like the US military specifying that every soldier is a /48, which has some implications on the amount of addresses they need. And then the German Military of Defence comes up to well, the German government, it says, OK, we need a big chunk of addresses and they will say RIPE isn't going to give us any or not that many as you might wish for. He is not coming up to complain; he is just trying to explain that outside of traditional ISP structures, some things are different. So this is more looking over the extending our horizon. Then, we have a new policy proposal coming up which is sort of in the do we need this, do we want this, give us feedback stage, and then we resume the discussion about things. That is basically what I have planned. Is there anything you want to see changed, you want to reorder? OK. I see nobody jumping up and down, so I take this as the agenda is perfect. Minutes. The NCC has done very detailed, very good minutes from RIPE 58. They have been circulated to the list and no comments received, so I take it that these minutes are very detailed and very exact. And unless there is feedback from that room, I am tempted to declare them final. So is there feedback on the minutes? Is there something inaccurate or incomplete? Is there anybody awake? OK. I hear laughter so you are awake. So by this I declare the minutes final and we can start today's actual work. Filiz, if you would be so kind. FILIZ YILMAZ: I was told when I click this it will show up. It's not showing up. Thank you. Filiz Yilmaz from the RIPE NCC. .I'm the policy update manager, and I do these updates in every RIPE meeting and Gert already mentioned what it is about, it's to give you an update on what is going on within our region and also go a bit beyond and talk to you about the topics that are commonly discussed in other regions. And one little disclaimer I will put on here is that I will not present each and every proposal that is being discussed in other regions, but this is a selective list that I saw as relevant to us here, so our colleagues already in their RIR updates yesterday gave it the full preview of what they had in their agendas. But this is more about, yes, trying to group them by topics, so it makes some sense, rather than just going through a full list. So if we start with the RIPE policy update. We have four proposals accepted recently. The first one is allocating and assigning resources to the RIPE NCC and we are very happy that we had this policy accepted finally. The problem here was that RIPE NCC, as the RIR or the organisation had some Internet resource needs too, as, you know, but we were so far out of the policy framework so we wouldn't receive any resources for quite a long while after we received some at the very you know, almost at the as you all know Internet resource needs grow in time and has been growing, especially within the last decade. One of them was IPv6 and this is all now started. We couldn't find a way that we could provide you with some good service running on IPv6 by means of getting some resources for ourselves. So now, finally, we have this generic proposal, we had this generic proposal which was cooked up by Remco and it is now dealing with recognising needs of RIPE NCC as well as an organisation. If they fit, if their need fits in the current policy framework that is available for all the LARs and the other end users, then RIPE NCC can fill in a request, our registration services will evaluate this request, but obviously we will not make a decision on it but we will send a recommendation based on that to a group of arbiters and those independent people will make a judgement on this. This is accepted in July 2009. So and I believe there will be some update about this because we just got some resources for the RIPE NCC. The second one is is a global policy, it's relating to the ASN blocks coming from IANA to RIRs and we have this policy accepted within RIPE region and one of the regions APNIC has also reached consensus on that and three regions are still discussing. However, I have a feeling that will go through there too. The main point here was, you all know, but I will repeat that for completeness here, is that we were quite running into some issues thinking that by 2010, January, the RIRs would not have enough 16 bit ASN to further assign to you guys, basically because, according to the current or in RIPE terms now previous policy, global policy, the IANA would cease making any differential between the two, 16 bit ASN pools and the 32 bit ASN pools. So far, those two pools, and they were evaluated separately, so RIRs could have and can have two separate blocks from those two pools. However, by 2010, January, IANA will start thinking of them as one block. They will merge the whole space in one go. And that would mean, due to you already have got the news, you have seen the low uptake in ASN 32 bit, the usage in that pool is very low and the other one is high, but when you merge them the resulting pool would still be too low to qualify for any ASNs. So RIRs would be an impossible problem in risk of not having enough resources, while IANA still had resource for that. So hopefully that will be sorted soon. However, like I said, since this is a global policy, after all the regions discuss it and eventually hopefully reach consensus, it will go to ICANN board for, only after that it will be policy in fact. Next: Yes, it's an interesting topic, removing routing requirements from the IPv6 Address Policy policy. This has also been this is accepted, as well, just last week. We make the announcements, I hope you have seen that. And our policy document has been updated, too. What this means is, previously, in initial allocation criteria for the IPv6, the RIR, the RIPE NCC would require to, for a commitment to to have the block to be announced as a single block, single prefix. Now, this is removed. And the main thing here was, this was actually recognised in the last RIPE meeting and then it came from a short discussion here and then immediately you guys reacted on it and proposal over it. It came out that operationally, now, people find that maybe the aggregation should be recognised and/or, in other words, policy should not dictate any routing requirements. It may be a recommendation, I believe there will be other work in the recommendations area, within the routing Working Group. However, as far as the addressing policy, the policy should not be forcing to announce one single block as such, just to receive address space. The other one is PI assignments for LIRs. This also came up quite recently and it has been concluded quite quickly. It shows that there is certain interest in it and immediate need. The idea was that some LIRs may want to have PI space other than receiving an IPv6 allocation for themselves, and this need has been recognised and this is accepted also last week, we have made announcements so these are in place. Now, from this slide on, are the ones that you are going to see throughout today in the second slot of Address Policy Working Group we will be discussing these. The first one is user final /8. Actually, the second one is also using the last /8 in a certain way so these two proposals are actually talking about the same resource and how to use that same resource. The first one, 2008 06, which is the number for the proposal, is talking about distributing that last /8 among all the LIRs at the time, based on a minimum allocation size, each of them will see the current allocation, minimum allocation size at the time, and that will be it. And another /16 will be reserved for unforeseen problems or future needs. While the second one is putting up a requirement, that that last bit of address block for the IPv4 should be solely used for those people who are putting efforts for IPv6 deployment, so the idea is there should be a down scaling with a factor of 64, so the minimum allocation size will be set to/27, and those chunks will only be given to those people, to those organisations who are going to be able to show that they are following the phases described in the specific RFC for their IPv6 development. It is RFC 5211. And obviously these two proposals were found to be competing with each other as they were relating to the same resource and Address Policy Working Group chairs decided they should be discussed together with relevance to each other. And yes, it's been a long process so far and we will see how it goes here. Your feedback will be appreciated, I believe, again. But the latest comments about these were focusing, first, on legal issues, some anti competitive issues could arise, that is what has been commented as and our Board has taken action on that and had some legal review being done and put together and I believe Axel will inform you about this more in detail today. However, if you want to see the full report, it's already in the list. So if you go to Address Policy Working Group mailing list, Nigel, yesterday, I believe has sent that mail with the full report. The other comment was questioning about do we need this, and should there be a last /8 policy at all, how much time will that buy us. Basically, the argument was if you are talking about a few months, which seems to be, then, you know, is it OK to change anything? And maybe changing anything in the last minute will raise some other fairness issues. And either way, if we do choose to change it, should we maybe put up a maximum allocation size cap within the discussions? But then, the next argument is, OK, what happens if the maximum size is not enough? We know that some people may need more, how do you push for these people to fit in one compact size. So these are the questions in mind and, yes, they are probably probably, we will hear more of these within today's session. Ensuring efficient use of historical IPv4 resources. Now, this is yet another, I find, interesting proposal because this is one of the first attempts to get legacy space within the system, within the policy work. So far, legacy has been policy exempt, so no policy would cover the legacy space as such. And the idea here, as we are leading towards the end of IPv4 address space, wouldn't it be an idea to start thinking of the efficiency in those legacy blocks as well, because they are the same, they are IP addresses, they are out there. So the proposal had a couple of revisions and now we have the third version published on the website and it's talking about applying the 80% utilisation rate over the legacy blocks as well. So if you are an LIR and you are holding some legacy space and if you need further allocation and you come to RIPE NCC, RIPE NCC will be tasked to ask you the 80% utilisation over your legacy block as well as your other blocks. It is also proposing that should be the case for first allocation, too, so if you are a new LIR, you are already holdings your holdings within legacy space should be reviewed. Well, one of the latest comments about that was that, OK, fair enough, yes, we could do that, but shouldn't the assignments be covered as well? Because not all legacy space appear by allocations by LIRs, maybe some end users have it, how do we tackle that? So that is another point of interest and discussion. Initial certification policy for provider aggregatable address space holders. This is under discussion still. I won't get into that, there will be a few slides, Nigel showing to you about that later on. Now, the global policy for the allocation of IPv4 blocks to RIRs with the tag, sorry for the long time, 2009 01. This is an interesting one. I told you about global policies just a few slides ago, that global policies apply to all LIRs and they are developed through the policy development processes of all the regions and then they go, as they receive consensus in all of them, it goes to the ICANN rectification and once it is rectified they govern all the RIR regions and all the RIRs and they relate to the practices between IANA and RIRs. Why is this interesting? Because it started with a group of people, authors from different regions but all regions were represented within that group of authors, and they came up with a proposal which was basically about return space, so after the IPv4 exhaustion of IANA pools, RIRs could receive some return space and if they do, they would return this back to IANA so IANA could, you know, reallocate them back to the RIRs, all of them again. Originally it started like that. However, it took an interesting twist because according to ARIN PDP every AC has the power or right to change the text as they see fitted, and what happened in ARIN region when this was discussed, their community gave some feedback and ARIN AC is tasked to take that feedback and change the proposal according to that feedback so that it can reach consensus. So when this happened, the wording changed in a way that, now, we are discussing if it is still the same proposal, because the twist in there may becomes a must in four other regions. So ARIN has a versions AfriNIC and APNIC and LACNIC and RIPE, we do have a version and those other three has already reached consensus, we are discussing and ARIN is discussing but different versions and ARIN's version, the return of space to IANA is a may, a matter of may, while in ours, is a must. This is shortly Axel will talk more about that and I think, today, you will be hearing these questions: OK, what do we do? How we tackle this? And is this still a global, can we call it a global, how can it be a global? These are the problems we will be seeing today or trying to solve. Now, in our region, again, we are looking at the review phase proposals, which means these proposals has a draft document already published and they have probably an impact analysis attached to them. IP assignment size; I won't get into the details of that. I believe Gert will wrap it up today but it's about putting minimum assume size over PI assignments, full stop. Run out fairly. Well, this is coming from some deep return that towards the end of the IPv4 free pool, one organisation may come and say, OK, this is my justified need and they justify the need but it is really huge and then they get big chunk of the left space and the other people, other organisations will only have that little part of the leftover space and is this a good thing, is this fair? Is there a perception of unfairness going on there? These were the concerns. And when this was raised in the previous RIPE meetings, there were a group of people who thought that yes, OK, you know, we feel the same concern and we would like to come up with a solution, so the proposal came by and the proposed solution is that, instead of saying, OK, your need is too big and go away, there should be a gradual reduction in the allocation and assignment period. So instead of you coming as an LIR and projecting 12 months, at some point in time your needs for the nine months will be taken into account and then after a point, six months needs will be taken into account, and it goes up until three months, so there is a gradual decrease. So the idea is, your need is still the same but you come to the RIPE NCC to ask for space more often so that, in principle, people will have a better chance of running out at the same time. So the big companies do not cover all the space and then, you know, two years later, a small company needs some space and there is not any more over there. Yes, there were some comments about this, as well, on the list, and again, one of them was do we have enough time for this to be effective? And the other thing was, well, the proposal is following fixed dates that are projected by Geoff Huston and one of the suggestions was, OK, maybe we can follow updates, not fixed dates but according to the gradual decrease in the free pool so those reductions will take place according to the as the free /8s reduce in time. Now, this is the end of the RIPE update. So far, all these proposals appear in detail in the agenda today, but now I want to give you some information about what other regions are busy with. And like I said, I will try to couple them up, group them up by topic and put some relevance around them. So, one of the first topics is user final unallocated IPv4 address space. So how the last bits of IPv4 pool should be used is a common topic in all the regions. People are busy with that. APNIC has just accepted not just, actually implemented, even the user final /8, it's the same proposal that we have here. LACNIC accepted another one where they will reserve a /12, but that will focus on mainly the new entrants, their target is the new entrants so it is for the new LIRs and they will assign /24s to the critical infrastructure as well. ARIN also accepted a proposal, which is for a /10 and they will allocate or assign /28 minimum or /24 maximum based on IPv6 requirements. So remember, I mentioned two competing proposals in our region, one chopping up the last /8 among all the members at the time, and the other one giving out space to those according to, so different regions went for different versions. You see here we are really competing and this is a regional difference. APNIC and LACNIC chose one way and ARIN seems to be going the other way. Running out fairly, it's not an easy one. ARIN picked up on a similar proposal to ours and they are discussing equitable IPv4 run out proposal and the principle is more or less the same. They are also talking about gradual decrease in allocation period. Their current allocation period is the same as ours, 12 months. They want also gradual decrease it but they chose to not to follow the I can fixed dates but, rather, to follow time line depending on the left over /8s, so when they see 20 /8s in free pool they will decrease it to 6 months. When it comes to 10 they will start applying three months and this is still in discussion. One other important point there which is different than ours is they also introduce a maximum allocation size when they hit the last /8, so when ARIN starts allocating from the last /8 there will be a maximum allocation size applied. That is not a mixed size; it will be the next complete CIDR prefix which will be less than or equal to the one quarter of the available free ARIN pool. And they keep their minimum allocation size anyway. Now, legacy space. AUDIENCE SPEAKER: Hi, is the mike on? Stacey Hughes, ARIN AC, I want to point out that we are actively discussing this, it hasn't been decided. All that stuff is not written in stone by any means. FILIZ YILMAZ: Legacy space: APNIC accepted the same proposal that we have here, ensuring efficient use of historical IPv4 resources, so again, they implemented the proposal that is that is an effort to put the legacy space into the system. It is a slightly more detailed version, though, than the one we have here. The difference is mainly the definition of the "historical resources." They have a very strict definition, what that is. And we don't we understand that is for RIR registration basically. And they have the same criteria, further allocation criteria to apply over the legacy space. Transfers: Well, this has been a long ongoing discussion and a concept within regions, four regions discussed this: APNIC, ARIN, LACNIC and us, obviously, we have already accepted that and implemented for almost a year now, it was at the beginning of 2009 it was implemented. And well, I won't go into the details. So far, in my previous updates, I was showing a table with the differences of the certain differences, metrics with factors of differences between regions, but at this point I think they have kind of evened out. What happened, ARIN and APNIC recently also passed through reached consensus over a transfer proposal and one of the very main topics that was discussed in all regions was that how would it happen? A transfer, could it happen just like that? An organisation agreeing with another one and they pass their address space to the other and all the regions seem to have agreed that they want to see the RIR in that process, and they justified that by putting a requirement of the requesting justification, so that principle is kept in all of the policy proposals and done recently with the accepted policies. And they all apply within region. So I don't have the metrics any more and hopefully I won't have a transfer slide in the next update, either. IPv6, and I am coming to an end: Single ago great, a must or not? A mentioned a proposal that has been accepted in our region recently which originated actually at the last RIPE meeting where people recognised the need, possible need of the aggregation management and this is recognised in other regions too. The main thing is, here, I mean, I think it will it is useful to understand that IPv6 historically, as a policy, is coming from a framework where aggregation was the most important focus point, it was more important than conservation at the time because one of the things that IPv6 was solving at the time was the routing tables, right? But in time, I think over the decade when now we understand that people are using IPv6 more on an operational basis, people are hitting to those operational problems and it's good to see these proposals coming because I understand that people want to do some address management and redundancy, you know, management over their allocation, they want to do some load balancing so they want to play around with their allocations. That is good. And what happened in ARIN, they discussed their they are discussing, at the moment, removing this requirement for single aggregate as well. LACNIC reached consensus about that and, interesting thing here, I have to mention, APNIC is discussing the other way around. APNIC had a proposal in their last meeting that not only the initial allocations should be a single aggregate, it should be explicitly put in the policy that further allocations should be announced as a single allocation as well, single prefix as well. However, that did not reach consensus and I was there and the proposer, seeing the feedback, he even said, maybe I should propose the other way around, dropping this requirement. And yes, this is went back, so we might see something happening in this regards in APNIC region, too. Can I finish and then yes. OK. This is my usual slide, if you don't believe me, go digging into those archives and let me know where I made it wrong. I dare you. But yes, I will skip to that. Now, I have still two slides. And these are my promotional slides. I never included these before, but yes, I normally keep an eye on how many people are subscribed to the Address Policy Working Group list, as well as a policy announce list, and this time I decide I am going to report it over the last three years. You may think it's not very significant but I still think it's a good sign that from within three years, it seems like one third of it had a one third of increase over the last three years compared to 2006 numbers and 2009. So yes, we are growing in as a number, this is a good sign and we want more people in, even, but number of people is something, what they say is another thing. This is more promotional slide. Again, maybe you won't think that this is significant, but I believe it is. You can see in the last three years, the number of POPs to the Address Policy Working Group has also increased so people seem to be more active which I think is a good thing, and yes, please keep discussing and communicating. That is the promotion. And now questions? (Applause) GERT DORING: Well, thank you for that very detailed report and sorry for interrupting. I assumed that the last slide would be the last slide. AUDIENCE SPEAKER: From LACNIC I want to clarify that in the for both the transfer and the summarisation of the IPv6 announcement we did not reach consensus yet so it's still under discussion. FILIZ YILMAZ: Sorry, OK, thanks for clarification. AUDIENCE SPEAKER: Also on the subject of transfers I believe that there is less uniformity across regions in APNIC they do not require justification for the allocations to be transferred. FILIZ YILMAZ: I believe they do but I can check this quickly and come back to you. AUDIENCE SPEAKER: OK. Good. Thank you. GEOFF HUSTON: APNIC. If you are talking about transfers, then up until the exhaustion of IPv4 is defined by until we get to the stage of the last /8 and a particularly different set of allocation policies, recipients of transfers need to justify the address space they would receive under the transfer using the prevailing policies of allocation, only thereafter, in other words once the piggy bank is empty, does that criteria disappear but we have nothing left to allocate anyway so prevailing allocation policies is is a weird term at that point in time. Thank you. GERT DORING: Thanks for that clarification. Thanks again, Filiz, and let's go on. I would just not use my slide for introducing Alex and explain what I have in mind. Alex from the NCC registration services policy implementation department has volunteered to sort of report back what they see during day to day operations in things that we might want to know about. Let's phrase it that way. Whether it was intention put in the policy that way or whether it was an oversight, is something that we need to decide then later on, so there is one twist to this today: I don't want to discuss solutions to these issues today, so we are happy to take questions that are need today clarify understanding of the issue at hand but we are not going into solution space today. I want you to think about this for 24 hours and tomorrow in the Working Group session after lunch, we have half an hour or three quarters of an hour dedicated to specifically discussing these issues, do we want to change anything, do we see this as a problem, do we want to come up with solutions, but this will happen tomorrow so you have time to think about this. Today, only clarification questions, please. ALEX LE HEUX: My name is Alex Le Heux from the RIPE NCC. I am the Policy Implement Coordinator and this presentation is about the part of the policy development process. I am sure everyone is familiar with the development cycle and here we are going to try to fill this evaluation bubble a little bit by providing some feedback from our daily experiences with some of the policies. As Gert said, today I will present a few items and people can ask questions to make sure that it's clear exactly what I am talking about. And discussion about solutions is supposed to happen tomorrow. Now, in May, we implemented the long awaited IPv6 PI policy and there has been some takeup of that, we have done by 30 assignments since May. The takeup could be a little higher probably because in the same period we assigned by 900 IPv4 PI prefixes and there are a few differences between the policies that may be the reason that the take up has been a little bit slow. The policy text are mostly the same, but there are a few differences. The main difference is in IPv4 policy, defines IPs, use to connect end users to ISP infrastructure as that ISP's infrastructure, while this, and this allows the use of PI space for, for example, ISPs to do cable or DSL or various kinds of hosting. The IPv6 policy has no such text in it, it does not define IPs, such to used as LIR infrastructure but it's very clear that about the fact that none of this PI space should be assigned to other parties. Now, from this 900 PI assignments in IPv4 that we have done, roughly half of that is to organisations that do cable or DSL and web hosting and that kind of thing. And there have been quite a few of these organisations that came to us for an IPv6 prefix but but the IPv6 policy does not seem to allow us to assign these prefixes to them. This is caused some confusion because there has been a big push to deploy IPv6 from everywhere, and these people come to us and they want an IPv6 prefix to deploy IPv6 in their network and we tell them they can't have one. So this is not entirely clear if that was the real intention of this policy, and maybe it's an idea too, because I will be presenting some different items. If there are any questions about clarification, that we do them between the presentations. If there is any questions now, I will be happy to take them? OK. This is a policy that has been around for a long time, the document is quite short, and it doesn't cause us a lot of difficulties. The main bit of text is this, defines what an autonomous system is, as a group of network or group of networks that have a single, clearly defined routing policy. On the face this is very clear, although what exactly is a routing policy? In most cases it's very clear, we have a network, it needs to announce prefixes, it's going to multihome, it needs an AS number. But we do receive quite a few requests from organisations that have a network and they want to have more than single AS number and the policy doesn't really provide many hand holds to evaluate requests like this. I have an example here. Let's say we have we have an ISP that has a Central Office and they have a bunch of POPs that are connected to this office and they might have peerings in the different POPs and from their Central Office. Most networks like that do their operations with a single AS number, but there are quite a few that would like to use multiple AS numbers for this, up to I think the biggest request we ever received is 15 for a network like this. The policy doesn't really provide many handholds to evaluate requests like this. The current interpretation is if your network is under one administrative control and is every bit of it are connected to each other, you can do your operations with a single AS number. There are some of these networks that are disconnected, for example, large countries like Russia, an ISP might have operations in St. Petersburg and the two operations might not be connected to each other. In these cases it's fairly clear that doing this with a single AS number is difficult and we will assign a second AS number. But if it's a single network that is all connected we tend to not assign multiple AS numbers. But the discussion with these requesters often goes very deep into BGP issues, so it's not entirely clear from the policy what they would like us to do in this case. Are there any questions for clarification here? RUDIGER VOLK: Are you actually using abstract policy where actually routing policy is technically defined terms as in people are deploying boxes that have a technically defined policy? ALEX LE HEUX: Yes. I am not sure what your... RUDIGER VOLK: Well, OK ALEX LE HEUX: Can I help you Rudiger? AUDIENCE SPEAKER: Network citizen. I think what Rudiger tries to say, the technical criteria is if you have a single routing policy, you only need oen AS. If you have distinct you have to have multiple ASs, is that what you are trying to say? RUDIGER VOLK: Exactly. And that is not related to how many personas you need in your schizophrenic mind, it's how much boxes you have deployed and have particular purposes. ALEX LE HEUX: Right. If I go back to this picture. What we see, we see organisations that have specified their routing policy and define in their single routing policy all the peers they have in all the various places. We also see organisations that have the exact same set up but they specify their routing policy per POP. At least that is what they would like to do. RUDIGER VOLK: And there are people who are doing essentially the same business and just have different ways to organise themselves. GERT DORING: We are starting to go into solution space so let's keep that part for tomorrow. Whether this is what we want or not what we want. Today is just clarification whether this is good or bad, we should discuss tomorrow. DANIEL KARRENBERG: I have a question for clarification. It's slightly related and I don't expect an answer immediately but it might be interesting to have an answer tomorrow. If you look at the burn rate of ASs, i.e., how many ASs get allocated or assigned between the different RIRs, it appears that since about three to four years, the RIPE NCC goes through many more ASs relatively to the other RIRs. This had escaped my attention, but Geoff rubbed my nose in it yesterday and it would be interesting to hear some less than speculative, some sort of at least some gut feeling from the RS department as to why this is, that is maybe just a bit of a tall order, but maybe to have some ideas about how the distribution of the various assignments happens, i.e. are we making just more assignments, are we making bigger assignments or do we give large bunches? Or is it sort of a different distribution where we have sort of have a normal burn rate that the others have and we have a few huge requests? And it would be really interesting to know this tomorrow. ALEX LE HEUX: I could give an answer now. DANIEL KARRENBERG: Even better, thank you. ALEX LE HEUX: If you look at the number of prefixes we hand out, either as PA allocations or DANIEL KARRENBERG: AS numbers ALEX LE HEUX: Yes, they are followed closely by the number of ASs we hand out, so what you see is that when an organisation comes to us for a prefix, either PA allocation or PI assignment, that request is not always, but in about three quarters of the cases, accompanied by an AS request because they intend to operate their own routing infrastructure. Is that an answer to your question? DANIEL KARRENBERG: So did I hear this correctly in saying, OK, we get lots of PI requests and they all want an AS to go with their tiny bit of address space? ALEX LE HEUX: Yes. WILFRIED WOEBER: Wilfried Woeber from Vienna University, and from that point of view Vienna Internet Exchange and National Research Network. I wanted to let you know that we are guilty as well of asking recently for just another AS number and the thing that strikes me with your explanation is that the definition of an "organisation" is pretty fuzzy and it's less sort of the routing policy fuzziness, the problem we are having is that in many situations we have one organisation with one routing policy with a well defined business case, like in our situation we are one organisation formally, but we are wearing different hats and underneath these hats, we are offering different services or different functionality in the network which requires separate specific routing policy. And although we are using part of our PA address space, there is complexity in the routing relationships between organisations which we think requires us or which makes it the most obvious and straightforward implementation technology to announce those things with a well defined routing policy within a well defined autonomous system and not playing funny games with preferences and no export and those things, just because it becomes unmanageable if the complexity gross. ALEX LE HEUX: Right, yes, I am aware not aware of your request but requests like it, and this is exactly why this is being presented here, because at registration services we do feel that there is probably, in some cases, a clear reason to request multiple AS numbers but we feel also that the current policy doesn't provide enough hand holds to really evaluate these requests. ROB BLOKZIJL: On the number of ASs that we use and which have been reported as being higher than in other regions, I don't believe that. In the absolute numbers, yes, but you should also realise that the RIPE NCC has about 7,000 members which is about the grand total of all the other RIRs together so I think if you look at the consumption rate per ISP, I don't think we are that excessive and I think we should also be careful not to interpret policies in such a way that we prescribe people how to run their business. There is no acute shortage of AS numbers. ALEX LE HEUX: It is not the intention to prescribe people how to run their business at all. GEOFF HUSTON: Just a small amount of data here to answer this question a little bit more: In 2009, since January 1st, RIPE have reported in stats files 2260 separate IPv4 allocations and over the same period 1,671 AS numbers, which is slightly more than 50% in terms of absolute numbers. In the same period APNIC has made 973 IPv4 allocations and allocated 367 AS numbers. So, the rates relative rates are certainly quite different and they are symptomatic of a different style and approach out there in deployment in terms of how the network is structured, I believe. ALEX LE HEUX: Thank you. RUDIGER VOLK: Short comment, though I don't have firm data on this, I think there we have to expect that a large driver in large number of AS number requests would be multihoming of rather small sites and that is quite obvious the very different problem from multiple AS for single organisation and I could imagine very well that the takeup of multihoming practices may be different in various regions. GERT DORING: I actually wanted to play back the ball to Geoff or to the APNIC folks here. I am not sure whether this is feasible, but if the different RS folks could maybe sit together and take a look at this, what the typical distribution is like, does the RIPE ASs, do they always go hand in and hand with the PI and APNIC ASs always just attached to a PA block and PI never come back for an AS and things like that. I think that is basically similar to what Rudiger said, that if, say, if all RIPE PI holders planned to do multihoming and need an AS number for that. And in the APNIC region people just use their PI to attach to an existing network and use their AS number, that would certainly explain why the usage rates are different. But what I do is pure speculation so maybe you have indeed some numbers that could help us there. I see Geoff already coming up with an answer. That was fast. GEOFF HUSTON: Let me offer one more data point here because they are quite quick to find out in terms of raw numbers. I said before RIPE had done 26100 allocations in v4 this year and 1,600 AS numbers, which does seem, in a proportion, slightly higher than APNIC. Over the same period, this is interesting again, ARIN have done 1,242 separate IPv4 allocations and have allocated 1157 AS numbers, which is much, much closer than as a one to one ratio than anyone else. I think there is something in there, but it's going to take a little bit of time to understand, because the next piece of work is to go through the Whois databases and actually see if we can match entities; in other words, this address block matches this AS number and then start looking at deployment to understand whether the ASs have been deployed in stub or transit mode in BGP, so if you are willing to wait, and it won't be tomorrow, we can certainly give you more data from this in analysing the RIR stats, if that is what you are interested in. GERT DORING: I think this would be interesting to actually see, well, we have seen the number that RIPE and ARIN are burning through ASs like crazy, and I am curious to why this is so and why there is a difference. I think there might be a good reason due to different way we run the networks and understanding the networks is always useful. GEOFF HUSTON: OK, I am happy to see what I can do, thank you. DANIEL KARRENBERG: With RIPE NCC Chief Scientist hat on. Just for the record, there may be no immediately imminent shortage of IS numbers and there is certainly no shortage of AS numbers in the foreseeable future. However, there is a shortage of ASN 16, like 16 bit AS numbers coming up in the intermediate in the immediate to medium term. Just for the record, so that people who may not be aware of this, heard this. GERT DORING: Thanks for pointing that out. AUDIENCE SPEAKER: RIPE NCC. I just wanted to add a little bit of information as we have been talking about the number of allocations made. Just wanted to add that in 2006 the RIPE NCC made about 1,800 PI assignments. 2007, 2200 like in 2000 like Alex was saying before each PI assignment questioner also requests an AS number to be able to route this address space on the Internet. GERT DORING: Which explains things a lot. OK, I think we are through with the AS numbers so let's go to the third one. ALEX LE HEUX: OK. IPv4 additional allocations and this is also known as the 80% rule. The IPv4 policy mentions the 80% rule twice and the 80% rule is the criteria when we will allocate an additional allocation to an LIR. In Section 5.3 it says that 80% of all the address space needs to be used. And then right in the next section it says that 80% of all their allocations need to be used. Now, this may seem the same but there is a subtle difference there, because it's entirely possible to have, for example, a large allocation fully used and then a small allocation which is completely unused, and still have 80% overall but not 80% of each and every allocation. RS currently has the more strict interpretation of this. Our position, if you have a completely empty allocation why are you coming for a new allocation? Although, there is some room to manoeuvre because there is, in practice, many reasons why an LIR might have an application under 80%, they might have gone through one or more mergers and might have acquired some allocations through the mergers that in some cases are a big mess and need to be cleaned up, they might be in the process of doing this but still need to expand their current existing deployment, so in cases like this we are a bit easy on them, might still give them the additional a allocation but make agreements with them they are working on filling up the existing allocations, make a note of this and of course, check this at some point. The reason why I am presenting this is that this is something that keeps coming back, time and time again. And it's been brought to the Address Policy mailing list a few times but, it's never been a very clear consensus either way of what the interpretation should be. And we are quite happy doing what we do now, but we do have regular discussions about this with our members and we feel it would be good to have them very clear clarification on how it should be or that it should be all address space taken together or each and every allocation individually. Policy text is is a little bit ambiguous. Any questions on this? Good. Then that was it for now. So, as Gert said, everyone has the chance to sleep on it and there will be more discussion tomorrow. GERT DORING: OK thank you very much for coming forward and explaining to us. (Applause) And for you, please think about these, think about what you think should happen, might happen, whether we see this as a problem and if yes, how to change the wording or the actual policy to adjust to it. Now, it's me again, just giving you an update on the routing issues, those that have not been directly involved at the last meeting and the time in between. Before the last RIPE meeting we had a policy proposal on the table where somebody said, OK, we are we are operating two different networks that are not connected. It's the same organisation, it's a single LIR, we want IPv6 address space for both. They are not connected, so we cannot use just a single 32; we need to have two different networks visible to the world. The policy document seems to imply that you are not allowed to announce more specifics; you have to announce the aggregate, and people people interpret this as the aggregate only. This has come up again and again so the proposal was to have some complicated criteria under which an organisation could receive a second 32, even if the first 32 is not full, and we sort of quickly figured out that we are not going to arrive at a set of criteria that would help everybody who needs this, why not at the same time giving people that do not need this multiple 32s for free, which the Working Group didn't want, so it was clear that there is no consensus to go forward with this and this proposal was abandoned. But we recognised the problem of these networks, so at the Working Group meeting we discussed that it might be more useful to have the operator community decide on what is useful regarding routing and the Address Policy community stop worrying about routing requirements so we had a new proposal in 2009 06 to remove this sentence from the IPv6 policy that requires to you announce this 32, or whatever size you got, as a single aggregate. This has been implemented and the policy text has been updated and it sort of gone from our plate, but at this point in time, we sort of have no very useful guidance to operators what is considered OK and what is considered excessive deaggregation, what are the reasons why you might want to deaggregate or not, so the routing Working Group has come up with a recommendation document that has been circulated to the routing Working Group mailing lists, I think some four weeks ago, it has not yet received any comment, which might imply that everybody agrees with the document but a few positive voices might be helpful and this is, of course, discussed tomorrow morning in the routing Working Group. So this is basically all I want to say about the routing issue. You are the operators, you need to decide what you want to see in the global routing table and what you don't want to see, accepting that there are networks that are different from your own and there needs to be a guidance document that you can point people to and say: "Hey, what you are doing is stupid, don't do it this way because everybody agrees it should not be done that way." Or if someone has real issues like "I have this complicated network and I don't know how to run it," point them to the document that says if you are in this situation, it's perfectly fine to do some level of deaggregation. But we really want this guidance document and it's an operator document so it's routing. I see Rudiger standing it up and shaking his head and obviously disagreeing with me about things. Please. RUDIGER VOLK: I am not really disagreeing a lot; there is one minor point in terminology and that is I am hearing in this audience always just deaggregation. I think what we should be what we should be saying is announcing additional prefixes, talking in the way that the only thing we are talking about is deaggregation actually gives a wrong hint. GERT DORING: I am not exactly sure what the current wording is used in the document. RUDIGER VOLK: In all the communication, including all the speeches today, there always has been only the word of deaggregation and well, OK, the thing is we do not need and we should not have constraints on what announcements are done out of a block, but we also should not talk in a way so that people get the idea, well, OK, it's all about separating up old stuff. GERT DORING: Rob? ROB EVANS: Rob Evans, author of the current draft. Yes, you are right, it says deaggregation, because that is the first word that came to mind. If you are happy with the intent of the document and there is consensus that we should change terminology to make it more politically correct than we can look at that, but we can talk about this tomorrow probably. GERT DORING: I agree with Rudiger just mentioning deaggregation all over the place is giving a bit of a wrong signal maybe. Announces multiple prefixes of your allocation. ROB EVANS: The word deaggregation I have got the impression from people, seems to set off ticks and no, no, no, no. GERT DORING: In the routing Working Group tomorrow morning, please come and discuss and make this a good document. That was actually my last slide for the first slot, this is the welcome slide for after the coffee break slot. But we are not done. I have asked Filiz to give another short report on the document surgeries project. Filiz, your report on this thing? As I said, some of the RIPE documents have become pretty well pretty much stitched together over time, like v4 policy documents having changed ten times over the past, and usually new policy proposals always changing specific words or specific paragraphs and not taking the whole document structure into account, because after all, everything you want to change is is a specific detail, so the whole document structure sometimes has become really hard to read and Filiz volunteered to start working on this difficult task to make the documents properly readable without changing their intention and it's proceeding. FILIZ YILMAZ: A short update about this whole thing: First of all, a reminder of what it is. If you have some black outs from last night or you haven't been here in the last two RIPE meetings you may not know about this. The main idea is, after every accepted proposal, we document these proposals in a RIPE document. It can be existing document so the acceptance of the proposal is realised as an update over an existing document or we create a new document. Now for the updates on the existing documents we came to the realisation of a problem, which is basically, getting the document where it is started or interrupted by each update. What happens there, often, the proposers have a specific wording choice; fair enough, we work with them together with Address Policy Working Group chairs at the stage of the proposal, even before proposal is public out there we do make some wording recommendations, but sometimes this doesn't work, it doesn't fit, so what we do, you know, it goes out with the proposer's choice of wording, as well as the style, and then you also have the problem of having the structure being interrupted by each update because every update to the document is is a patch, basically, you insert new section or you delete a previous selection so the flow, it's very hard to maintain the flow through those updates. In RIPE 57, there was a very simple suggestion to run a project just quickly not quickly just to review the language of the documents so that you don't change anything but just structure and the readability is improved. So, since then, what we have done, we have come up with a plan, which got consent of the Address Policy Working Group chairs and we announced this plan to you in RIPE 58, which was the last RIPE meeting, so the plan is very simple: We will draft it in the NCC, we will get initial confirmation from the Address Policy Working Group chairs, Gert and Sander and we will publish a draft to you guys for your review which will stay there for a month, which is our normal review time period, according to the, you know, full policy development process, as well, so we kind of took that as a framework. And after that, one month, if you are happy, then we will publish the document as a new document with the suggested wording, new wording. Now, if we receive feedback, obviously we will have to do iterations over these past points. Now, six policy documents will be reviewed within that methodology and what we have done so far, we have already reviewed two, AS numbers and IPv6 for IXPs and there was a reason to chose those, because they are quite short, and yes, if you come up today with a decision about the routing practices within the AS number document because we can also integrate that but that is another different process or a different matter. But yes, and we want to learn from these documents how the process would work, because this is a first time, really, we are doing this after the IPv4 document got real review about ten years ago. What happened about these? The chairs gave their consent to us recently and, now, from the next few couple of weeks you will see these being announced in the list and then you can review and let us know what you feel about that. However, I want to mention one important thing, which was a challenge we faced as we already anticipated throughout the whole practice, is the formatting basically, as well as you know choosing the right wording. I must say, I was going through in my slides, in my previous update slides, and I saw this transparency is the key word in there as well, and it is very important, we want to make sure that you understand the changes that we come up with and we see them as, you know, literal changes, not in the core policy change, because our aim is totally not to change the policy. Policy is there, the framework is understood there, the rule, if you like to call it, is well known by everybody; we just want to find a better way of describing this in our documents. Now, it's not an easy task, you can imagine. There seems to be, also, personal preference factors we run into between the chairs. The way I think something is clear is totally unclear to Gert, and vice versa, so we decided, eventually, that we will try to cover all tastes and personal preferences, as well, so with the same content, same update, updated draft, we will publish it in two formats; while in one all the changes will be marked, like the way we do today when we have a drafted document, you know, old or original text compared to the new text, and the other one will be just the pure document, full document, and you will see it won't be interrupted with any breaks and in both we will provide the summary at the top, so where the major changes are done, so you can go to the relevant section. Now, if you have any better ideas to do this, please let us know, and we will see if we can incorporate that as well. So this is my update about that. GERT DORING: Well, again, thank you for undertaking this project and it's definitely needed but it will not be easy, as you have said these documents need work and actually reviewing the changes for, is this still the same policy while the complete wording looks different is not going to be easy and the only way we can make this succeed is with your help, so we are changing policy documents and this needs to be done very much in the open, very much with the whole Working Group or the whole community to be absolutely clear that we are not sneaking in policy changes by bystepping the BGP process, this is making the documents for readable and orderly. So you need to review this and tell us, "we don't agree with this specific change" or "yes, this is OK, go ahead." Yes, again, thanks for taking up this project. Thanks to you for actually showing up here after the party and now we go into the coffee break. We are good on time. Please be back at 11:00, enjoy your coffee break and then we go into the policy discussions. Thank you.