Routing SIG transcript
APNIC 25
Routing SIG: 1400 -1530
Wednesday, 27 February 2008
PHILIP SMITH:
I think we should try to make a start, we'll try to make sure that the presenters' laptops work and so on. If you're lost, this is the routing SIG meeting, the APNIC Routing SIG, part of the larger stream in APRICOT. If you intend to go to another session, it is not in this room, it will be somewhere else.
I think I should make this announcement because I've had far too many people getting completely confused about where things are. The only definite place where the APRICOT program is is on this website. OK, this is where the program is, I've put it up on the screen. Please consult the website if you don't remember where you're meant to go. The information in the program is out of date because we had some last-minute changes due to cancellations and illnesses and so forth. If you're in any doubt as to where you're meant to go, please consult the website.
Now, the agenda that we have for this 90 minutes, we have a house keeping section which we're going to go through. We have some administrative items to go through pertaining to the Routing SIG, so we'll have a short discussion about those.
We have three presentations from Vince Fuller, Yasuyuki Hamada and myself. For the other presenters, please remember the sequence that we'll be doing them in.
As for the housekeeping, when you're asking questions, please use the microphone. As you may have noticed, we have stenographers who are basically writing every single word that I am saying on the screen. The session is also webcast. So, if people shout out from the middle of the room, the web cast won't be able to hear you and the stenographers will not be able to hear you either, so please use the microphones. When you do, please state your name.
Also, for presenters, this doesn't apply to just the Routing SIG, it applies to all other sessions as well in this room. Please speak slowly and clearly, it helps the transcription and it helps people who are listening on the webcast as well. So, this is the first of many housekeeping items that I want to cover.
Next one, the APNIC Helpdesk, that's running in the Osmanthus Room on this level. If you have any questions or concerns for APNIC, please go to the Helpdesk. They might even give you a fabulous prize for something, so they tell me! The APNIC social event is tonight supported by Nominum. It is in Shintori 5, I have no idea where it is, but buses will take you there. You can get tickets for transportation from the APNIC Helpdesk and in any event, it will start at 7pm tonight and run on until 9pm. If you're interested in going to the APNIC social event, please go to the Helpdesk and get your tickets and turn up for the transportation.
APNIC also have an online survey and the URL is right there on the bottom of the screen. You can go to the APNIC website and fill out the survey and the big prize is a digital photo frame!
Tomorrow we have the APRICOT closing event. That's being held at the Chung Shan Hall, I don't know where it is, but transportation will be provided. The social event runs from 7pm through to 9pm, sponsored by Cisco. We also have a brief online survey for APRICOT. Most of that pertains to the v6 session that we had this morning. If you would like to give feedback on that and your general APRICOT experience, please complete the survey. I know that is quite a few surveys, at least two surveys, but if you could give us some feedback for the APNIC survey and APRICOT in general, we would really appreciate that.
So, I think that was all of the housekeeping we can now get down to the Routing SIG itself. We have three Chairs, I'm Philip Smith, over here we have Tomoya Yoshida and Randy Bush who are the two other chairs. You can reach us by e-mailing SIG-routing-chair@APRICOT.net. There is a list with not a great deal of traffic.
How to subscribe is there on the screen.
So to the action items that we have to consider. So, the first one came from the last APNIC meeting, where basically we had to have, we had a situation really where APNIC has the Internet Routing Registry working group. It is an informal group who are basically looking at Internet routing registry and Internet routing registry issues. It didn't really have a chair and didn't have much status either. There was a mailing list, but we had a little bit of discussion and then it fizzled out.
The question was raised, what should we do with this working group. Working groups at APNIC are generally short-lived to look at a particular topic, and then either the topic is or has a successful resolution or it gets spun into the Special Interest Group or it just shuts down or goes away. So, the question really is, what should we do with this? Given - before I try to answer the question - given the Routing SIG is really chartered to be looking at routing issues, whether it is research or technology or operations within the Asia-Pacific region, it seems a natural fit that the IRR working group should really find its proper home within the APNIC Routing SIG. So, this is what we as chairs are proposing to do. Rather than shut the thing down! Because, we believe there is an important contribution that the IRR can make to the Internet. But then, the other question is the Routing SIG future. As Chairs, we've observed the Routing SIG last met during APNIC 23. That was a year ago. We did not have a meeting in Delhi for APNIC 24.
Most of the content which has been volunteered for the Routing SIG - really since APNIC 23 - has been contributed to the APOPS general plenary, because most of what was contributed was operational content. We considered it of wider interest. It was also part of making or kicking off APOPS to make APOPS something within the conference. We considered the idea of disbanding the Routing SIG all together because we hadn't met, there's been virtually nothing on the mailing list, there's been no specific content that could be fitted into APOPS as such. But then, on the other hand, we have Internet Routing Registry Working Group looking for a proper home. Our conclusion really is that the Routing SIG should carry on and should focus more on some of the research and technology areas, whereas the more general operational areas of interest would carry on finding a new home within APOPS.
So, I was considering standing up here saying, right, we should just get rid of the Routing SIG. There are procedures for business banding a SIG where basically I need to talk about it in front of you all and make a proposal, but we're not going to do that. We're going to propose that the Routing SIG carries on, but looking at particular topics like the Internet Routing registry Working Group.
So, after all of that, does anybody have any comments about, well, it is a non-proposal because we're not proposing shutting anything down, but this proposal that we will move the Internet registry, is that acceptable to everybody?
DAVID WOODGATE:
Could you perhaps reflect on, given the uncertainty you've given with the Routing and SIG future, and keeping it going, that's specifically for the IRR, would this be a good time to perhaps re-state what the charter of the Routing SIG group is on that basis, what you're expecting to achieve?
PHILIP SMITH:
This is where I have to go digging around on the APNIC website. I'll just go to the APNIC website and I'll pop the text up on the screen. I had to click on another link, so we're getting there.
I think I'll just read the charter out, it's probably easier because the stenographers will write it on the screen.
Basically, the Routing SIG examines important issues of Internet routing and policy in the Asia-Pacific region and globally. These issues would include Internet routing table growth, deaggregation of provider blocks, routing stability and flap damping, routing security and the Internet routing registry. I guess that would answer your question, Dave in that the IRR Working Group could find a home here.
DAVID WOODGATE:
So given what you've just read out and given a lot of content donated to APOPS as more operational issues, some of that material in the charter seems to reflect more to operational issues, some things might be technical. I can certainly see a role for a Routing SIG, specifically with IRR to find registration of Routing SIG, does the Routing SIG need to be tightened up a bit?
PHILIP SMITH:
Sure, we can do that. So, I think what we could do is, if the Chairs look at tightening up the wording a little bit in that respect, and of course that on the mailing list. And I think what we're really trying to look at is generating more interest and content in the community. I think it is reasonable to say that most of the content tends to come from the three of us, rather than from the community. This was intended to be set up for. But yes, I think what we'll do, we can look at and propose some wording for the mailing list, I mean, if people have suggestions, they're very welcome to e-mail them to us or pop them on to the list. We can see where we follow up with that.
Do my co-Chairs have any comments to make? Anybody else have any comment to make? No? OK. Good enough!
OK, so I think with that, I think we'll move on. So, the presentations we have, we've basically got the three presentations, so I'd like to invite Vince to come up here and give the first of these about Network 240/4 and the future.
240.0.0.0/4: The Future Begins Now
VINCE FULLER:
OK, good afternoon everybody. I hope everyone had a nice lunch. My name is Vince Fuller, I work for Cisco, or rather I'm employed by Cisco. Some people debate whether I do any work there. What I'm going to talk about is a presentation I've done at the IETF and at NANOG and at RIPE. If you've been to those, you can sleep for 15 minutes, because you would have seen it already. It is also a very brief presentation, probably more suited to a lightning talk, but they wanted it on the agenda.
I'm going to talk about the address block that begins with 240/4. It is all of the /8, 16/8s that run from 240.0.0.0. What was that, slow down? OK. It is the address block which runs from 240.0.0.0, the 255.0.0.0, is that better? Is that too slow?
What is this all about? Graphically, this is what the IPv4 base looks like, and the picture here represents 6.25% of the total address base, the same size as the multicast address space. It is not a huge amount of space but not a trivial amount of space either. Currently, the 240/4 space is defined for future use by IANA, and the question here is, as the title at the top says, the Future is Now, because there's not much point in reserving something for the future when the entire space is about to run out.
So, if we want to use the space, what are the choices we have or how it could potentially be used? The first choice is to turn it into public address space like any other unicast address space that's currently in use today. Potentially, that could mean it would be allocated like any other space. There are some fairly serious issues with that in that most computers today will not recognise anything beginning in this, anything in this address block as being valid. Before it can be used as general purpose address space, we have to get all of the systems patched and it would have to be not only the people who are assigned the addresses, but also the people they may want to talk to.
Second choice is to make it a new block of private address space like RFC 19 space. As they say, let consenting adults use it as they wish. In other words, if you know that you have a bunch of systems that have been patched to use this new space, well, go ahead and use it and set it aside for that purpose. That's actually what this draft, the Wilson-classe-01 Internet Draft talks about, proposes that we do that.
The third choice is to split it into public and private, that's the best or worst of both scenarios, as for any public use, it would work on the systems. For private use, it would have the same restrictions. And the last choice is what we're doing today which is nothing.
Our approach, the authors of the draft, myself, Eliot Lear and Dave Meyer of Cisco, we came up and we were looking at this and talking over dinner about six months ago and we decided, let's write a draft on what we think should be done. What we think should be done is, let's leave it for the politicians and the IETF to decide how it should be used but let's advocate that it is used, which means, get the software changed so that when there is a decision, the systems will all be ready to use it. So, that's basically all the draft says is, it points out some of the issues and then states, yes, there are issues, but, if we're going to have any chance of using this, let's get all of the software changed so that they can be used today. Again, future use doesn't really make much sense given that the future of the IPv4 address space is limited, so it doesn't make sense to reserve it. Again, that's what the draft says. There is running code out there, basically. I actually came up with a suite of patches for the Linux Kernel modifying five files. I submitted this to the Linux developers and tested it on two different Linux trees. One for the system and one for the laptop and then gave it to the kernel developers who said that they could come up with a different version, which is good so long as it comes into the kernel. It already works on a Mac. If you look at the code, there is one place where it checks, where a 240/4 is there. That is if it is acting as a router. There are not a lot of Macs used as routers so you can turn on the Mac today and it will work.
It has also been committed to Solaris. Somebody told me two months ago that Solaris is taking this and it is coming soon to Solaris. There are other places where it is needed, the obvious case is where there was no commitment to modify any Microsoft operating support systems. If you want it, you should tell your vendors. That applies to the router vendors like Cisco and the host vendors and you should encourage people that this might not be a bad thing to happen.
Again, possible issues: The first one is sort of a religious, political issue. There are people who are worried that if developers are spending a lot of money and 240/4, that will delay getting IPv6 deployed. Considering that I, as a non-kernel developer could get the patches done in less than a day, I don't think that it will hold up a lot for someone who knows what they're doing.
Some would say that anything that prolongs the life of the IPv4 address space will slow down the IPv6. Again, it is a religious argument. I don't think it is true, but why cut off your nose to spite your face, as they say? If people are going to be using IPv4 for years and decades to come, let's make it as easy as possible for them to use their system, rather than deliberately putting impediments into it.
What about router support? There are surprisingly few places there. People look at this at Cisco that check for 240/4. There is old line card firmware that checks for it but I don't believe that a lot are in use. The bug idea is committed to ISO and IOS XR. If you saw the announcement of the new Cisco line, the 240/4 will work out of the box with that thing. They're doing less development on that and testing 240/4s on that since we have the DCOS developer in our pocket. I'll talk more about this tomorrow.
I don't know what the status of Juniper is if anyone else has information, please feel free to stand up and update us. Again, the biggest issue is Microsoft and the particular issue that has been raised to me is that 6to4 automatic tunnelling systems need to know whether a particular address is considered public or private. Geoff, you're shaking your head, that's not the case?
GEOFF HUSTON:
No, that's not the case.
VINCE FULLER:
In any case, I think that's a limited argument, given that you could still make the operating systems use the space, without going into the tunnelling. So, Geoff says there aren't issues about tunnelling, I'm happy to believe you, I hope you're right, but I just put this up there because that's what somebody in the know told me. Kernel changes going forward.
In summary, it is not a panacea. It will not solve the world shortage of address space, but it might make life easier for people who are using IPv4 for a long time to come. There is no consensus, whether it should be private or public space, but again, this document says we're agnostic on that. We want to see the software updated so you can configure it on the interface boxes. The code changes are simple, less than a day to put it into two different kernel trees to test and run it. It is already in place in many cases. The memorial, the Nike slogan, "Let's Do It".
ROQUE GAGLIANO:
Do you have any review idea about support from 30 or 40 blocks, routers or IOSs, etc?
VINCE FULLER:
I don't have any direct comment on that, I know that one of the things I tested that on is the opening software distribution, the mode on the router, that's one of the things I represented, in the software, I know that the request has been submitted to the developers. As soon as they get around to it, it should be easy. Does that answer your question?
ROQUE GAGLIANO:
I think it is also a big part of the question to accept that.
VINCE FULLER:
It will take time.
OLE JACOBSEN:
What is the process for if this is IANA reserved space, does the ICANN Board have to pass a resolution to bring it out?
VINCE FULLER:
I think I'll let Geoff handle that. We wrote the draft and threw it into the IETF process because we were told that was the right thing to do and I don't know how to get beyond that without the commentary.
GEOFF HUSTON:
The changes that occurred in the ICANN and the IETF in the end of the '90s, in essence, changing the allocation at that level in the IANA registry,is an Internet Standards action. So, to make 240/4 something other than future use would actually be conventionally an RFC published through the Internet standards process with an explicit IANA consideration section. So, it is an action over there that says, "make it be so". There is no ICANN board resolution or anything like that.
VINCE FULLER:
OK, does that mean that we have to make sure that the Is are dotted and the Ts crossed and the IANA consideration is probably written?
GEOFF HUSTON:
Coincidentally, over there is Paul Wilson who is the author which has an IANA consideration in this which says, "Make it something else." So you don't need to do it, it is already in the list.
VINCE FULLER:
Excellent.
PAUL WILSON:
Hi, thank you Vince for being here. I'm very glad to see this being raised in this meeting. I did write a draft that proposed exactly what you are saying, plus a designation of the spaces. I think what you've done is much more sensible and much more intelligent, because it separates two orthogonal discussions and allows the discussion about privateness to happen later. While everyone is saying that of course, the issue here is the difficulty. The difficulty here is getting all of the hardware changed. So, thank you very much for being here. I'd like to know what the Chairs, whether the Chairs are proposing to put this to the room for a motion of support for some kind, even though this is strictly not an RIR policy. I think it would be useful to do. I would also be interested to know if it is going to any of the other RIR policy forums, because I think votes of strong support, and I would suggest urgent support from the addressing community might help to bring it through the IETF process, or is that too open?
VINCE FULLER:
You're optimistic.
GEOFF HUSTON:
That is very optimistic.
PAUL WILSON:
As Vince said, if we don't do it soon, there will be no point. So, that's why I suggested...
VINCE FULLER:
To some extent, it is happening already. So, that's a good thing. If we need official information of whoever, that would help motivate any vendors who don't think it should be done. I would hope.
RANDY BUSH:
It has to be done at the IETF because the RIRs are not allocating this over IANA. They have not been allocated the space.
DAVID WOODGATE:
Just a comment on the future debate about public versus private. For that space, I fully support freeing up the 240 space for use. But, I imagine that if you're going to try to use it for public space, even if you had the code today and all of the IETF approvals and everything else, it would take; I'm getting would take at least three to five years before you could use it.
VINCE FULLER:
More than that. I tried to point that out in the presentation, but it would take a long time before every system could recognise the addresses. That's one of the reasons why we're not advocating that it is public. We're just advocating that the software is changed. You can imagine some niche cases where you could use it, certainly to control the devices to know what software you're running. One of the things we've been doing on the list effort that's independent of this is using this address space as sort of our EID space. It is a well- defined space, and the only thing that will be used there are the tests. I would say three to five years would be very optimistic before you could allocate someone a publicly-used block in this space. 10-15 years would be more realistic.
GEOFF HUSTON:
Any sense of urgency should have happened years ago. This is nothing to do with exhaustion. What it has to do with, we're probably stuck with IPv4 one way or another and it is not clear what happens with the extension of public and private allocations. So in the fullness of time, one way of providing more private space assuredly is to progress along this path. It doesn't have to happen tomorrow, or in urgency, but it does have to happen.
VINCE FULLER:
From a commonsense point of view, and I'm going to say something politically incorrect, but I realise that the IETF process there have little to do with each other. It seems silly to reserve this space when there is, when the space is running out. We should do something.
GEOFF HUSTON:
This is my point. We're in that point. The legacy environment is going to stretch out for some time, and it is not clear that the public and private boundaries will shift in any other way. But I'm also hearing a huge amount saying we have to persist on that stacking. We're going to need more private space in the long term, not in the short term, but in the long term. I think we're singing from the same song.
VINCE FULLER:
I agree, but in fact, within the three authors of the document, there are differing opinions on whether it should be public or private, and I happen to be in the private camp. I'm happy with Wilson class E draft, but some of my co-authors are different.
Anything else? Then, I will turn it back over.
PHILIP SMITH:
Thank you. Just out of interest, what do people think in general? Do people think that using 240/4 has some mileage? Certainly in giving Paul the indulgence of his request. Anybody think we're wasting our time?
So, for the record, there were one or two "yeses" shouted out and nobody said anything about "no". So, I guess we leave it to the authors of the draft to pursue. OK. Thank you for that.
Next presentation is Yasuyuki Hamada.
Trouble with messy IRR
YASUYUKI HAMADA:
Good evening. Please give me a few seconds. I'm from the NTT Communications. Sorry!
Sorry, taking a long time.
OK, good evening. This is the Yasuyuki Hamada. So today, I like to make my presentation, the title is 'Case Study:Trouble with Messy IRR'.
Actually, this presentation is for working through an issue. First of all, I try to introduce my name using the Chinese way. Thank you very much.
This is today's agenda. I have five. The first one is background of this presentation. Then next one is, case study 1: Route Leak Trouble. Number 3, Case 2: Growing the Size of the Route-filter. And the fourth, my plan to shoot the trouble.
Background of this presentation. As you know, IRR is the database of the routing information. There are so many uses for checking the route.
Some ISPs are using it to generate route filter. So, if the data is not, if the data is unreliable, we can not use it, because we rely on the data. I think we should maintain, it's quick information to other operators.
So, please remember what is IRR? I quoted from the RADB introduction.
As you know, IRR is registration, a routing database. So, many people use them, so, I think that we should keep it good.
This is in our case, in AS 2914 network, in our case, we use it to generate routing. OK, the user registers their information to our database. Also our IRR mirroring with other IRR. And the server gets information from our IRR. Then, our server generates data which pushes it to our router. This is not good to see.
So, IRR is a very important thing because we generate routes from it. So, to check some cases, in this case, the trouble route leak trouble.
In this case, you can see the bottom, but this bottom router, the specific route. Then, this router and this IRR gets the information from there, then they register them automatically.
Some of you may see that this information, auto generated route object. This object is generated by human. I mean, this IRR gets the information, which is generated. Or some to generate a lot of information. So, as I mentioned, the IRR, each IRR is mirroring, so this IRR gets information from this IRR.
So, this ISP is to generate the route data from their IRR, and this IRR has won information from this. Also, this router advertises space to the next router, and the next router has wrong, and this information.
So, in this case, route leak happens. In this case, if this ISP set up the prefix, then it goes down.
OK, so next case, growing the size of the route filter. This is one from IRR. ISP has this one prefix. If we use IRR to generate route filter, then in this case, just when we want, this is only one prefix. But, in some case, people divide more space like this. One prefix divides into the fifteen prefix, but the perfect length is different. In this case, generated to the 15 times.
So, I ask you, some action for the IRR. For ISP, don't register routes automatically. How can I say, very easy if you use it automatically registration, but this means, if someone uses IRR when you run filter generator, if you do this, the filter is not reliable. So, I think that you should, you don't use automatically registration.
But, if you need to use this basic expiry date for the prefix. And for IRR users, please try aggregate routes. Please don't divide small sizes. For IRR data, the implementer of two using what is related to the IRR.
With this type of description, for the prefix, one line just needs one prefix, but if you can please use this kind of link. For example, 61.120.144.0/20-24. If you can use this, so we can, I don't know, but we can generate one prefix.
Also, if you can please mark for the route object. For example, if I want to register no export, then the mark is no export, for example like this. If someone marks like this, how can I say it? If the two get the information from the IRR, they can find a more specific route, the two may divide to this information.
If we use this in the future, we might use this route filter size. So, you need to keep your data clean.
OK. Any comments? Sorry, I'm not good at English so my presentation is not...
RUEDIGER VOLK:
While making good use of IRR data certainly has lots of issues, I'm certainly not able to address all of the issues that came up during the talk. There is one question that I have for you, I am using all the data which is floating around, or are you carefully selecting the source databases that you actually put some trust into?
YASUYUKI HAMADA:
You mean, I use one IRR or all IRR?
RUEDIGER VOLK:
When you run your filter generator, you are issuing queries to our proposal database, and you have the option of saying, well OK, can you give me all the stuff that's in the database regardless of which source it comes from. Remember the RPSL objects have source text, and there are lots of databases where I would say, OK, well nobody really knows who is running them, what is the value of it, what are the policies? And you have the option of saying, "I want to have the database and a resolution restricted to data from a given set of sources". Are you using that?
YASUYUKI HAMADA:
Um...
PETER SCHOENMAKER:
The easy answer is that they'll be filtering the data and the databases he's supporting so it doesn't if you don't register all of the routers in the database, that is what is supported.
RUEDIGER VOLK:
If one person is using one particular database, does that mean that I should be using queries or other customers that are actually using it, and use all the crap that happens to be around in that?
PETER SCHOENMAKER:
The customers will register all of their crap in the database because they're a customer, so you may clean up some of the data by not mirroring the other databases. But in general, they're going to register whatever they need to register it in to get the routes in the filter so they can announce those.
RUEDIGER VOLK:
OK, if you take it into our own administration database, I would say at least from your point of view, we're not using an obscure one.
PETER SCHOENMAKER:
So people will use /14s and /15s and /16s automatically and they will just register them in the NCC database or one of the reputable databases after that. That's not the main problem that's seen that may be a problem, but it is not the main problem.
RANDY BUSH:
Randy Bush speaking from the floor, not a Chair. There are only 50 of these things. They're all crap. Deciding how crappy each one is, is a contest of don't want to enter. NTT actually does mirror their customer's databases.
The only database running which I'm aware of, who does not just mirror everybody is RIPE. Everybody has to register wherever they register, and if they have any origins in Europe, they have to register in RIPE too. But, that's just a pain because of RIPE's arrogance.
RUEDIGER VOLK:
Do you consider using the defined authorisation schemes with this? Even if nobody else cares to use it?
RANDY BUSH:
You don't know whether somebody else uses it or not, and that's not RIPE's criteria for mirroring. RIPE mirrors APNIC which does not use those schemes, so let's not be hypocritical about what RIPE does, OK. The fact is that there are only 50 of these, the IRR data is formally weak. But it is better than nothing. Mirror them all, use them all, try to do it well.
TOMOYA YOSHIDA:
So, in Japan, we have some authentication. We go between the IRR system, so when someone wants to register to the JANOG system, if someone doesn't have the permission to register some route, that route is not the route. Then we have some trials in Japan.
RUEDIGER VOLK:
OK, so you're claiming that source JPNIC, or I'm not quite sure what the tech is, means that there is someone who knows about the addressing and actually has a policy that this is secure data? So, it is not all crap, as Randy is telling us and while, OK, again I would make the point that the RPSS scheme, though it is not perfect security, it is much better than none. It's securing the European data under Source RIPE. We are pretty selective about using the data that's around.
RANDY BUSH:
I'm going to cheat and not walk down again, but you are having a contest at who is better at making silk purses out of sows' ears.
PHILIP SMITH:
I think we should wrap up the discussion. It's been good to see so much discussion on the floor from two presentations, both this one and Vince.
YASUYUKI HAMADA:
Sorry, I want to show two slides and I think that as you know, Pakistan stopped the YouTube, so I heard that Pakistan advertises this hijacking route to outside, so if you use IRR data to generate data, you can stop this kind of trouble. And one more thing. I also am belonging to Japanese community and the general meeting in JPNIC in Shinagawa Tokyo. So, if you have the chance to come to Japan, please join our conference in the JANOG meeting. Thank you.
APPLAUSE.
PHILIP SMITH:
Thank you very much.
BGP Deaggregation Report
PHILIP SMITH:
OK. So final presentation, my turn. Just really, just an update on, well, my little deaggregation report thing and BGP aggregation in general. So for those of you who haven't seen what the whole aggregation thing I have been going on for two, three years now, I'll go on with background why I'm doing this and talking about the deaggregation report before I show you the latest spiralling numbers.
Basically, this all started when the LINX attempted an aggregation policy for their members. That policy failed, even though the members voted for it. They were happy to vote positively for something they thought would be a great idea but when it came to the crunch and they had to implement it, it seemed to be more a case of, "Somebody else can do it and we will get around to it." So the policy actually failed.
What we did, and I got together with Mike Hughes, the CTO from LINX, and Rob Evans from the UK academics and research network to build on the LINX recommendations to produce documentation for the industry in general. So, did the work under the auspices of the RIPE working group and it became RIPE-399. The URL for the document is on the screen there. After review by the working group, it became the RIPE-399 document.
What it does is discuss the history of aggregation, causes of deaggregation, the impacts on the global routing system, has a look at some of the available solutions and then finishes off with some recommendations for ISPs.
So, I'll just go through some of them, I won't go through the document in massive detail but I'll go through some of the highlights for information.
It first covers the classful to classless migration that was in '93, '94. The cleanup efforts of 192/8. The CIDR report started off by Tony Bates back around 94 timeframe to encourage the remaining ISPs to adopt classless routing and do some aggregation within the network.
If you remember the NATs stage, rather than handing out class Bs, they were getting blocks of class Cs, the intention of the CIDR report was to get the ISPs who had been given the blocks of class Cs to join them together to one aggregate. So the CIDR report was relatively successful, I thought. It was mostly ignored through the late 1990s. It was amusing when I visiting ISPs in this part of the world for my new job. Some ISPs thought the CIDR report was a hierarchical list of the biggest ISPs in the world. It was used by marketing departments to say "we are big". It wasn't, you were the biggest contributor to the routing system.
That report is now part of the more extensive BGP table analysis that Geoff Huston is doing. The document covers the introduction of the Regional Internet Registry system and providing aggregate system space.
Some of the causes of deaggregation that I have found going about in the course of my day job has been things like routing system security. People announce /24s, it means no-one else can DOS the network. It is fairly questionable, though the YouTube incident shows it worked in that case.
Reduction of DOS attacks and miscreant activities. A lot of ISPs don't want to announce address space they haven't used yet because it attracts noise. Commercial reasons. People said "mind your own business". Me working for a router vendor didn't help. Leakage of IBGP outside of local AS, one of my hobby horses. A lot of BGPs don't understand that 'I' stands for internal, inside, and for EBGP means external, between the systems. A lot of people happily leak their entire EBGP to the outside world and assume people are happy.
Traffic engineering for multihoming was blamed a lot. There is a lot of traffic engineering going on. Many people to traffic engineering by spraying out /24s and hope it will work. Because it sometimes works, you get away with it and they carry on doing it. Legacy assignments, all those pre-registry assignments, but when the registries came along it all cleaned up, I wish it was true.
Impacts, it shortens the router lifetime as vendors underestimate growth requirements. Probably less so now, but more in the early years of the Internet. Memory upgrades on routers usually just went from say 32 meg to 64 meg rather than 32 meg to 5 meg to 12 meg. So it shortened the depreciation of the routers, which was a bit unfortunate. In the ISP we worked on a depreciation cycle of around five years, which is ludicrous really when you look at the turnover of routers. So it has increased costs for ISPs and the customers. It is the same deal for router processing power: Big routing table, more CPU updates and so on.
Routing system convergence, a larger table, things slow down. Things slow down, the network becomes less stable because it takes longer to repair itself when there is a break. Yes, you can throw faster control plane processors at it, but is it doing anything to fix the problem? It is the usual joke about computers with operating systems: Big, faster systems with more features to slow everything down again.
So you have the network performance and stability issue. Slower convergence, slower recovery time, longer down times, customers get less happy. In fact, they get quite a bit more unhappy because the network takes longer to repair itself.
Solutions, there have been a few over the years. The CIDR report published every week looks at the global aggregation efforts; how well people are doing. It publishes the top 30 service providers who could do better at aggregating. My routing table report, which I run with the help of APNIC, split it down into per-registry-region basis. A lot of filtering recommendations out there, all the training around the world, tutorials. The project Cymru folk and so forth; reflecting best industry practices as part of their function.
We have had the CIDR police. There are no real police on the Internet as such but we've had the CIDR police who are basically a group of individual volunteers who send emails to ISPs saying, "We notice you are announcing so many prefixes, but if you aggregated, you could announce two. Would you like assistance to fine tune your configuration, maybe?" It happened from 1998/99 to 2000 with varying levels of success. A lot of the excuses mentioned earlier came from there.
The BGP features, NO_EXPORT community - a lot of people use for local peering. NO-PEER community that is documented in RFC 3765 that no-one's implemented far as I'm aware of. The AS_PATH limit attribute, every time I've done the presentation, I say it's an IETF process somewhere, as far as I know it is still an IETF process somewhere.
Various provider-specific communities. Some ISPs will provide specific communities for their customers to assist with traffic engineering. Some ISPs know what communities are and they'll use them. Others have never use of a BGP community or what it does.
The RIPE-399 recommendations basically encourage ISPs to announce the initial allocation as a single entity. If they receive subsequent allocations from the registry and they are contiguous and bit-wise aligned, then this should be aggregated. ISPs should attempt reasonably prudent subdivision of aggregates for multihoming. If you get a /19, announcing it as 32 /24s is not a good idea. A lot of people do multihoming and traffic engineering by chopping up their aggregates.
All the BGP enhancements are discussed. It is IP-agnostic, it works for v4 and v6.
Looking at deaggregation specifics, the second part of the presentation: There is the CIDR report on the website, a beautiful box on the bottom of the screen. You can put your AS number in there and it will tell you how well you are doing with your aggregation. It will make recommendations to what you as an ISP can do.
My routing report basically took the idea of the CIDR report when Tony was running it and subdivides it down to a regional Internet registration basis. It was motivated by registries saying, "We see the CIDR report but we are not in the top 30. Can we see who is in the top 30 for the Asia Pacific?" I have headed down that path.
I added the deaggregation factor in the report. Basically, looking at the routing table size versus what I reckon the aggregated size could actually be. It is quite interesting; I always believed all the way along that the deaggregation of the Internet was pretty constant value; there was some kind of deaggregation happening. I didn't, for a minute, realise it was going the way it was. You are going to see in the next few slides.
So looking at it on regional basis, what, globally first, 247,000 prefixes in the BGP table today. Depends on your view, but mine is that big. Deaggregation factor for the world is 1.96. Basically, it means, if we aggregated the announcements made today we could reduce the BGP table to 124,000 prefixes.
If we look at the different regions, I hope you can see them at the back. I have put them in order of deaggregation. At the top we have Europe and the Middle East: The RIPE NCC service region. Deaggregation factor 1.6; North America, the ARIN region, 1.77. Asia Pacific, 2.72. Africa 3.15 and Latin America and Caribbean 3.96. Those are the different deaggregations happening in the Regional Internet Registries around the world.
Put these on a graph, it looks more like this. So the line right at the bottom here, this is Europe, the RIPE NCC service region. Right at the top here, this is the LACNIC one, the Latin American/Caribbean deaggregation pattern. Notice it started high and shot off through the clouds. Just over four a few weeks ago and dropped back again. Sort of hovering around the four mark.
Africa is this green one in here. Notice, a big jump about two months ago for the AfriNIC region. I have no idea what caused it. There was a big collapse in this piece. I need to check if it is the same time as the cable cuts happened in, offshore in Egypt. But it looks around about the same time. A big drop here, and then back up to the usual numbers. The blue line is the APNIC service region. Just showing steady, steady increase, steady growth. The yellow line the global average, see the global average has been moving gently upwards and just short of two now.
If we look in the different regions, we can see - I have started off in Africa - I've done the top 20 ISPs by order of the possible savings in the routing system they could make. But LINKdotNet announcing 443 networks, could save 412 by doing aggregations. Pool their announcements to 31. Egy Net could go down to 207 if they wished, and so forth through the list. Some spectacular ones here, down by 92 and so forth.
Going to this part of the world, ISPs seem to love being at the top of the list. Most savings can come from Sify, BHARTI, BS&L. ChinaNet has done an amazing amount of work, they have been No.1 for a long time. They have been working very hard and I know the folk who are working there, working very hard to improve this. I must applaud the effort that has been made there. It used to be No.1 by a long mile. But now we see most of the ISPs sitting happily at the top of the list and very little attempt being made to improve what they are doing for the Internet backbone.
North America, the usual favourites here, Cable One, Covad, Time Warner. Covad is the favourite, 1,042 announced, 1,032 possible savings. They could just end up announcing 10 prefixes. They are the ones that stand out there, you look through the whole list, quite a few, just amazing amount of deaggregation happening.
Latin America and the Caribbean region, again, looking through the list here, I mean, 426 possible savings, 416. Typical example of some of the savings that could be made.
For Europe and the Middle East, TEDATA quite happy at the top, announcing 390 prefixes; they could save 383 very easily, ending up with just seven. Maybe the marketing people like them being at the top of this bad list, I don't know. You see the same thing, most of the service providers tend to be newer entrants into the Internet industry. Most of the ISPs here are the newer entrants.
The range of operational practices between the registry regions is interesting. You find the newer part of the Internet is contributing an unfair share to the size of the routing system. The ISPs that have been around since the early '90s understand what to do and are doing good things. The more recent comers don't basically care what they are doing, announce any old thing and they do get away with it.
From the router vendor point of view, we are just quite happy to sell bigger, faster boxes with more memory, bigger CPUs, because the industry is quite happy with this self-pollution.
RIPE-399 is only a recommendation, not a mandatory document. We hope the RIRs will include pointers with each allocation they make and ISPs pay attention to it, take a look at it. Are you trying to follow some of the good practices with your own network? There is lots of training out there, plenty of BGP tutorials, plenty of workshops and so forth that show how to do this.
But ISPs decide training costs money. Most of the training that is part of conferences do not cost anything compared to commercial training courses; but they don't send engineers to learn what some of the good practices in the industry are.
So the final slide is 'Please Make RIPE-399 your good BGP practice document'. And that's all I have. Are they any questions at all? No questions? So, where are with time? Well, if there are no questions this brings us to the end of the Routing SIG agenda for today.
I just want to remind you of some of the things before we close for the coffee break. I said this at the start: There shouldn't be any confusion with the program if you go the conference.apricot.net website. If you want to know where to go or where your presentation is, please go to the web site and consult that because this has the definition information.
I would like to thank the presenters, Vince Fuller and Yasuyuki Hamada. I would also like to thank my two co-chairs for helping with this Routing SIG meeting, and this brings us to the end of the session. Thank you for attending the meeting.
Coffee break is from now til 4:00pm. Thank you.
APPLAUSE
(End of session)
