______________________________________________________________________ DRAFT TRANSCRIPT SIG: Policy Date: Thursday 2 March 2006 Time: 9.00am Presentation: prop-032-v002: 4-byte AS number Presenter: Geoff Huston ______________________________________________________________________ KENNY HUANG: Before moving to the next session item, I would like to change my chair to our co-chair Eugene Li and he will chair the next session. Thank you very much. EUGENE LI: Hi, everyone. This is Eugene Li, the co-chair of this policy SIG. I will chair the following two presentations. Let's start with today's only policy proposal, presented by Geoff Huston from APNIC. Please. GEOFF HUSTON: This is a really quick proposal and it assumes that you are familiar with or have read a report I did at the previous APNIC meeting on the consumption of AS numbers. So this proposal is actually about what to do when we're looking at the expected exhaustion of the 16-bit AS number pool. So, at some point, sometime between now and around 2011, we need to actually transition the new part of the Internet into use 32-bit AS numbers and possibly assist in transitioning the existing part to use the same 32-bit numbers. Although the second part of this, upgrading the existing infrastructure, is actually not required as part of this transition. So this policy proposal is actually aimed at assisting the industry, vendors and deployers, in transitioning to use 32-bit numbers. What we're trying to do is to plan ahead rather than panic at the time. Because we know on consumption rates that the AS number pool of 65,535 numbers will exhaust. It will exhaust some time around 2011 or so. There doesn't seem to be a panic rush going on there. This is not like IPv4 addresses. But certainly right now on the routers you run, from a number of major vendors, there is no code in your routers to support the use of a 32-bit AS number if you happen to get one for your network. Now, if you don't get one, you don't need to change your routing system. But, if you do get one, you need new code. So, at some point, we need to send some signals out there to the industry about what kind of dates are required for us to do this transition painlessly. The essential attributes of this policy is to ease this transition, to try and inform all of you and the industry at large what actions will happen on what date so you can plan for that and give very clear dates in terms of registry actions themselves. So the underlying thing here - and I've got it in the wrong font colour but if you have a look at draft IETF 4-byte AS Number Proposal, you will see there is something that describes the elements to bootstrap ourselves into that domain. I've got some work on the projected exhaustion of that space. Henk Uijterwaal presented some work yesterday from RIPE looking at a similar scenario, slightly different bent looking at reclamation but, between the two of us, both of us agree that there is a problem coming up and considering this is now not a very small operation - the Internet is a big one - and there are 21,000 ASes out there at the moment, a few of you need to consider what you're doing and understand that, in the size of your organisation's network, you might take some years to get the necessary testing and deployment phases done before you're ready. So we'd like to do this in an ordered fashion that doesn't produce surprises. So the assumption here is that the IANA actions in setting up a 32-bit AS number registry, which we believe is relatively simple, should be documented and completed by the 1st of January next year. In essence, all this does is take the existing number registry and add another 4.3 billion numbers to it as a single-line entry. It doesn't change any other structure of the registry. The proposal itself is hopefully relatively simple. It actually just nominates three dates. The first date is the date the proposal becomes effective and commencing 1 January next year, if you want to experiment or otherwise use a 32-bit AS number, you will be able to ask explicitly for one of those numbers from the number pool. If you don't say anything, you will get an existing 16-bit number as you'd always have gotten. So as of 1 January 2007, the proposal is that, if you want to use a 4-byte number, you can say so and the registry will give you one according to its normal allocation practices. There's no change in the allocation policy, just the number we're dealing with. The next date is very closer to the predicted run-out date for the 32-bit numbers. One would hope that folk building new networks or wanting new AS numbers, would have been able to source and deploy new versions of BGP in their routers to keep with 4-byte AS numbers. So the proposal is that by 1 January 2009, we flip and that 32-bit numbers will be allocated by default. In other words, the top 16 bits will be non-zero. There should be, according to the prediction, sufficient AS numbers left in the 16-bit pool such that, if you want a 16-bit number because you haven't got access to new versions of BGP by then, you should be able to ask for them explicitly. So one would hope that, on 1 January 2009, if you meet the allocation criteria, by default after that date, you would get a 4-byte number unless you explicitly ask for a 2-byte number. The proposal disappears on 1 January 2010. After that, it's one 32-bit number pool. You should consider all the numbers by 1 January 2010 as 4-byte numbers. Down there (refers to slide) - what do I mean by 2-byte to 4-byte? The 16-bit numbers are from 0 to 65,535. The 32-bit only numbers are from 65,536 through to 4.2 billion. And after 1 January 2010, we say it's a very big number pool and it extends from zero to 4.3 billion. What it doesn't do - no more private AS number pools. It doesn't define any documentation-use AS numbers. It doesn't continue any legacy pool after 1 January 2010. It's just 4-byte numbers at that point. This policy would effectively vaporise on 1 January 2010 and we're dealing with a 4-byte AS number pool. APNIC can adopt this policy unilaterally as did can any other RIR, so it doesn't require coordinated actions, nor does it define additional AS number allocation practices. This is merely a case of offering some dates and some default RIR registry practices commencing at each of those three dates. And that's the proposal. End of slides. Any questions or comments? IZUMI OKUTANI: Izumi from JPNIC. We actually, you know, shared this proposal within our community and we didn't have a big, you know, comment or problems, but there was one question. And I personally think that it would probably lose the spirit of the proposal, but there was a question - how flexible this date could be and if it's a really rigid date and it's got to be, you know, set on this date no matter what or if some unexpected problems happen it could be reviewed and changed again. That was the question from one of the community members. GEOFF HUSTON: Certainly, the issue here was indeed to specify dates for, I suppose, quite a particular reason. When this was first aired as, "We have a problem, we should do something about this," over a year ago, one of the major router vendors had responded along the lines of, "Well, you know, we put features in routers when customers ask for them and basically we only listen to customers who spend money so that, when customers scream that this is an important consideration for purchasing our gear, it will be in there and we haven't heard anyone so we're not doing anything," which struck me as a relatively backward view of this problem. Since then, I believe, that particular router vendor has, I hear second-hand, put this particular feature in BGP on their implementation track. But, of course, then comes the issue of when should it be done. And we know pretty much that, if our current allocation rates stay the way they are, we had better be completely finished with this transition about around 2011. And knowing some very big networks take some certain months if not years to do the testing and deployment of this kind of stuff, then this is trying to offer some dates to the industry at large to say, "Look, by 2010, we'd better have solved this." That's why the first date, 2007 says, "If you're ready and want to use it, you can." The 2009, some three years hence from today, it's a case of saying, "We really should have got most of the software fielded. If you feel that you haven't got software ready in your BGP, you can ask for a 2-byte number and will get it." So it's not that you won't have access to those numbers, it's just by default, we expect most of that BGP to be out there by that date. So I think I would respond in saying, there are good reasons for having dates but if, as an ISP, you can't make it, certainly by 2009 to 2010, there's a way out. You can use a 2-byte number if you want one. It's not a case that you have to demonstrate anything particular. This policy proposal says, "You just simply have to say, 'I'd like a 2-byte number please'." IZUMI OKUTANI: Thank you very much. I think we support this proposal and I think it would help in the transition of AS numbers. Thank you. GEOFF HUSTON: Thank you. EUGENE LI: Any other questions or comments? No? GEOFF HUSTON: OK. Thank you. EUGENE LI: Since this is a policy proposal, we need to look for consensus here. Anyone who is in favour of this proposal, please raise your hands. (Pause) Thanks. That's 14 hands. Who is not in favour of this proposal? Please also raise your hands. (Pause) OK. This is consensus. Thanks, Geoff. GEOFF HUSTON: Thank you.