These are unedited transcripts and may contain errors.
EIX Working Group session on Wednesday, 4 May, 2011:
CHAIR: Welcome, good morning. Various other ways of saying hello. We will come to EIX Working Group at RIPE 62 in Amsterdam. Unfortunately, due to a technical issue, the con although the content will be transcribed, it won't be appearing on screen and going out on the audio casts, apologies for that. It will be available for review later on. We have two sessions this week, one on Wednesday and one on Friday, I have to say it wasn't the Chair's idea of a great layout but that is the cards we were dealt so we have put the IXP sessions on the Friday morning at 9:30, we thought we'd give you an extra half hour in bed after the dinner, and we will put the main operational content into the session this morning.
We are starting off with Andy talking about some possible IPv4 policy, some updates on services from Henk from AMS IX, some renumbering experiences from NIx.CZ, quit production from Keith Mitchell on some work that ISC is doing around route servers, and then Job is going to talk about some more routing work.
Anyway, first up, do wave volunteer for a describe? We do, thank you very much aman do. Do wave volunteer for a Jabber scribe? Thank you. Anybody who is listening in and wants to send questions, they will be brought up to the microphone during the session.
Minutes for RIPE 61 I think have gone out. Does anybody have any comments or corrections they'd like to make. Can we approve them as a Working Group? I take that as approved. Does anybody want to add anything else to the agenda? No. Great.
ANDY DAVIDSON: Thank you. Thank you, Fergus. I am going to talk to you today about new Internet exchange points, most people in the room are probably interested in peering or representing an established exchange point but it's become clear that due a few conversations I have had recently or in a few conversations I have had recently, there is some work to do regarding leaving resources for future Internet Exchange points and well, the, it's not very interesting to talk about IPv4 any more. We are in a post IPv4 world. But we still want to make some new exchange point in areas of the world where there are no exchange points today. The areas of the world that most need Internet Exchange points don't have them at all, so my, I think the slides are coming back. Yes, an example of a so here is one of Todd under wood's holiday snaps that he insisted I put in and it's a typical area of the world without any Internet Exchange point. It's important for the people in the local community to go and put a switch there and run some services so that traffic doesn't traverse and go away across the world in order to go back to two people locally. The process is simple, you go to your regional Internet registry and ask for some numbers and there is a policy which says you can go and get some IPv6 for your peering LAN services and right now IXPs tend to get IPv4 PI for their peering and LAN services but IPv4 PI is about to go away. When RIPE NCR are down to their final /8, there will be no way of getting IPv4 PI any more. So, that means maybe as Internet Exchange operators we need to do some work and I thought about this and wonder if it's possible to do IPv4 prefix exchange over the v6 session and, well, yes, it is but you still, it looks like you still need to accept a v4 next top so it doesn't take the problem of not having any v4 left, away. Additionally, if we start to look at doing v4 prefix exchange over v6 session we don't get process separation even though that has been demonstrated to be desirable in almost all BGP implementations and it will be make troubleshooting harder because your Nokia and processors used to one way of troubleshooting a session that is down or poor performance and if the v4 reachability say and there is no v4 version that is going to make troubleshooting much harder, so I think this might be a really sucky way of carrying on. Why don't we look at using RFC 1918 space and that is all really undesirable because it means that operators who have got routers can't do any RFP protection. Also, we can't make the assumption that RFC 1918 space isn't already in use, the same space isn't in use within an organisation anywhere else so if the peering LAN is numbered the same as some other LAN inside the organisation, that will cause issues for anybody wanting to connect to the exchange. Troubleshooting is an issue because a lot of peering LANS are advertised by BGP so that the exchange shows up in a trace route and if you use RFC 1918 space that can't happen any more and people often debug other exchange point issues but looking at the reverse route and say which network is responsible for a node and you won't be able to publish for for who is on the peering line if you use private address space.
So again, this seems like a really sucky way of carrying on.
So then we might say, v4 is dead anyway, why don't you do v6 peering at exchanges? I think that is a fair question, as well. But, in my experience, I have seen that exchanges have tended to be a driver for IPv6 advocacy so if an exchange starts with v4 and v6 services in a part of the world where there is no exchange the exchange is the neutral body, to act as a catalyst for v6 knowledge sharing so I think that it's probably counter infewtive to use the v6 dominance and v6 future argument here because having a dual address from a peering LAN is probably one of the ways of getting v6 adopted.
So if there is no technical solutions maybe we need to look at some social solutions like not making any new exchanges. I don't think that is very good solution, either. The places where I am talking about needing to look after by creating exchange points will benefit enormously from the creation of a new exchange point, so I think that just saying we have got enough exchanges is not just a reasonable way.
So my solution that I would like to propose is that we actually hold back an additional /16 from the final /8 of the RIPE NCC will assign from, in order to give just two Internet Exchange points.
Now, we already define Internet Exchange points in some other policy in RIPE so we already have policies that say this policy only applies to Internet Exchange points. And that is well defined and understood so it's not as much work as it sounds to go and discuss and document this policy. What I am looking to do, I have had private discussions with people and discussed in other forums about this but what I am looking for you, you guys in the room, to do, is for people to come to the mic to say yes, we think it's a good idea to hold back some IPv4 space for new Internet Exchange points we get any sort of support from the room or if we agree that EIX as a Working Group support this idea, I will go to address Working Group tomorrow and propose this as a new policy. So anybody want to do that, first of all?
AUDIENCE SPEAKER: Will Hargrave from LONAP, I along with many other IXPs fully support this proposal.
JAMES BLESSING: I think it's a good idea, the only thing I might say is maybe taking the 16 from existing space now rather from the last /8 to have to stop us having lots of things taken out of the last /8 for various different purposes and that is the only change.
KURTIS LINDQVIST: I think it's a good idea, what James just said is a good idea or not, I can't make up my mind on that. I think I would forever to be from the last /8 but no, I think it's a good idea, go for it.
Wolfgang: I also think it's a good idea we should do that.
Mr. Woodcock: All the prior suggestions are good ones. I think you might want to be careful not to say the only for new exchanges because one of the most critical needs will be for exchanges that have a /24 right now and grow past 250 or so participants and suddenly need to be in a/23. And in general, there is this issue of exchanges having that sort of renumbering bump that is difficult and figuring out whether you want to reserve later blocks for exchanges at the time that they start if they are in places that look like they might grow quickly
ANDY DAVIDSON: Thank you for that very good comment.
Christian: Support from myself and the Vienna Internet Exchange in general, probably could also try to find a sponsor. There are a lot of organisations around which have huge amounts of IPv4 addresses, probably somebody doughinates a /16 for the Internet Exchange community.
ANDY DAVIDSON: Possibly. I think some of those people are hoping for eleven dollars an IP.
HENK STEENMAN: Support for the proposal.
AUDIENCE SPEAKER: Alexis. I also support both the whole idea and James Blessing's idea and maybe the final, if yes, the final document should also say what is the minimum assignment for an IXP.
ANDY DAVIDSON: Another very good point.
Anders: We support the idea of doing it. It sounds like good and fair thing. As long as it doesn't mean that we might be putting a price on getting an IP pool. I know it will be for an Internet Exchange, but we already have a thing where you can just become an LIR to buy your IP, which you can't, with you you can, so I was actually thinking about maybe saying these shouldn't be routed; they should be used for the IXP but might not suggest that should not be announced.
ANDY DAVIDSON: I think there is a long standing tradition that Address Policy and routing policy don't overlap in RIPE policy land, which I think will be really good to preserve because if we go down the road of opening a can of worms that is nothing to do with the proposal, we are not going to passed it before the v4 has run out and also, a lot of IXPs make a deliberate decision to route or to announce their peering LANS because of because their members ask them to and in order for debugging to work so I think it's a fair suggestion but I think it would be difficult to run with those ones. OK.
AUDIENCE SPEAKER: Agreed.
Simon: I also support this idea.
ANDY DAVIDSON: Thank you.
Peter: From NIx.CZ, we also support this idea.
ANDY DAVIDSON: Thank you, so I think the message is I have to wake up tomorrow morning at 9:00 and go tell people in Address Policy this is what people think. It seems we have consensus we would like to do this work so thank you very much for your time and support. Thank you.
(Applause)
CHAIR: Thank you. Next up is Henk. And I think Andy would also be happy to have volunteers to help him write the document so if anybody is interested, come and catch him at the end of the session.
HENK STEENMAN: This is about a couple of new services by AMS IX we developed in the last half year or so. Yes. So, the way we dime this new services was by a lot of discussions in AMS IX general assemblies, we supported we got support for the ideas bay number of surveys we sent out, I will shortly go over these to give you an idea how much support we have for these services. So, the new services we have developed and we will be presenting an officially launching shortly our, we will allow customers instead of members, we will start the inter IXP services we will also SLAs, not only in the inter IXP service but also connections to the Internet peering VLAN and we will do the that soon.
So, early 2010, the AMS IX management and boards and got a lot, there was a need for some new services on the exchange, specifically initiated by the request from mobile operators to start supporting IP X as follow up and then the most difficult part of that, or at least for us, the most controversial part was the introduction of SLAs on services on the exchange. So, we had a lot of discussion, thousand support that in the AMS IX or, we went to a lot of discussions with the membership, we added we had to introduce a number of extra general assemblies to get all this sorted out and decide if we are going to do this and how we were going to do this. In the meantime, while discussing the inter IP X and SLAs, a number of members came up with the suggestion we would not only support SLAs in the inter IXP service but also on connections to the peering the Internet peering VLAN and maybe on other services. In the same time, we decided that we would allow customers instead of members, I will come back to that later. And because the general assemblies are generally not attended by many people, we thought we find support for all these new ideas in a number of surveys we sent out.
So, on the surveys, we sent out two; one in November last year to the administrative and organisational community of the membership, and one in February to the technical membership, to give you an idea of the response, I got some pictures. We got about 115 participants in both survey, which will a little bit over a quarter of the membership and then the response came back was a little bit biased against towards the Netherlands. From the total membership, 37% comes from the Netherlands and in the surveys, the return was 47%, but it's a little bit biased towards the Netherlands, but not much. And then we got response back from 22 other countries, and the what you see her show the typical area geographically of the participants so we have national operators to global operators or operators on the US or in Asia. So it's a pretty good representation of the membership.
The same goes for the connection speeds; when you look at this, we had 28% of the respondents have a connection on gigabit Ethernet and 30% on 10 gig and smaller percentages on larger connections or on smaller connections, which is also similar to what the general membership has.
And also, for the type of members like ISPs or carrier or content distribution networks, also pretty much the same as the total of the membership. So we considered the surveys a good representation of what the membership was.
So, the first thing we introduced is allowing customers instead of members. The reason for that is we got a lot of feedback out of potential members or people that wanted or companies who wanted to connect to the exchange, that becoming a member was really a difficult thing to connect to the exchange. Their laws or their organisations really had a difficult part to get that through.
So we, in the general assemblies, we decided that from now on, we will allow connections to the exchange from companies that will not become a member of the association. For the rest, it's the same contract, but this is the single thing that is missing and of course, because they are not a member they have no voting rights in the general agemably, they just take a service on the exchange.
Then the other big new service, very impacting on the exchange, specifically on our operations, is introduction of SLAs, so this was, as I said, initially introduced to support the inter IXP service and then it was suggested to offer this overall, and we tested the interest in member surveys and then what we got back in the initial survey in November was that there was, indeed, 31% interest among the respondents for an SLA on their Internet peering VLAN connection, and about 77% were willing to pay up to 10% on their port cost for that and another 9% a little bit more and more. And then when I send out the survey to the technical community, would have expected to get a lower number than this 31% but what I got back was, an interest of 62% of the membership has an interest on an SLA on their connection.
So, SLAs in the AMS IX membership is a well accepted and interesting service.
So, we are going to offer that, starting with this summer. We will officially announce it at the next meeting (summer). Roughly, this is the way we will implement it and what we will offer. At every PE router on the platform, we will connect the device, the devices will, between each other, measure the performance of the exchange, and will measure packet loss delay and jitter and report on that on the website and then if you have an SLA on AMS IX and your connection typically deviates a lot from the reported numbers, you can make a call to the knock and say that your connectivity does not adhere to what we public and we will investigate that and see if you are entitled to a penalty or whatever.
We also guarantee on your connection an availability of 99.99% and that is roughly it. All the details will be further published on and explained on the AMS IX meeting next month.
The other interest is inter IP X. I think I have already got into this at last meeting. It's a follow up on the GRX service we already offer. GSM A saw that the whole, also in the mobile networks, all services going to IP only networks, they already had the GRX infrastructure where the mobile network operators connect to GRX operators, and any GRX operators connect with each over other AMS IX or two other exchanges in sing pore or Washington. So we can use this model again for general IP services we call it IP X and we design IP X operators that service a subset of the N M Os in the world and interconnecting the IXP operators we need to get something like an exchange or they can do it correct or whatever but the exchange is explicitly taken up in the model defined by the GSM A, the IR 34 standard or model, or whatever they call it.
Also different from GRX here is that the IP X service explicitly states there will be to a certain amount of quality of service between the MNLS and IXP operators are obliged to give SLA on that, and because AMS IX will take part in this, we should be part of this end to end SLA between the mobile network operators.
So, we are going to do that. How we are going to implement this: We want from the IP X operators two connections on the exchange on two different locations. They will, of course, be in a separate VPLS instance from the Internet VLAN. We guarantee a higher availability, 99.95% because they have these two connections, we can do that a little bit higher than on the Internet VLAN. And then the service parameters of performance, as I described earlier, are part of this SLA, too, and they confirm to the highest defined quality of service in the IR 34 document.
We started the customer beta service this month and we will be fully operational in July on this.
And then 100 gig Ethernet. The question on the surveys was, if you currently connect at least 10 gig do you plan to upgrade to 100 GE in the 2011 /2012 time frame. On the general question, if people were going to upgrade in 2011, we got this answer. The different colours represent, red is connections that are currently smaller than gigabit ethernet, orange is 10 gig or more and white is gigabit ethernet or multiples of those. And 48% of the respondents said yes, we are going to upgrade and roughly of 60 percent will upgrade in this year with 50 to 100% or more, which is interesting for us because we can plan a little bit ahead on that. And then the answer on will you upgrade to 100 gig or take the 100 gig services we got a response that 15% is going to do that. It also gives us an idea on issue we should invest in 100 gig equipment.
Associated with this we had a question on the type of optics people are interested in. The IEEE officially has an optic standard which defiance 100 GE of a single mode fibre up to ten kilometres. These optics are really, really expensive and there was a group of companies that has defined same standard in MSA called 100 gig ELR 10 which defines 100 gig optics consisting of so lanes of 10 gig which makes it an awful lot cheaper. Based on that, when we want to offer gigabit and we use LR so optics we can use that at a time of seven times 10 gig, if you want to use L R4 we will ask you 10 times gigabit. On the question, what kind of optics want to use, half of the respondents said something like we don't know yet, and half of the other half said LR 10 and also people answered L R4, so we cannot really say we will standardise on LR 10.
Time frame for this: We did lab testing in AMS IX lab in April, worked out fine. Of course, there were a couple of problems, still, but it's all pre production hardware and software. We will have a trail with a customer with live traffic somewhere the second half of May, and then we will have official service in, probably the second half of June this year. And then as I said, we will allow two types of optics and using the 10 gig 100 gigabit HR 10.
Last question on the route servers, that is another not really an service; it's an extension on the existing services we do now. We asked if people were satisfied with the current route servers we offer. 14% think it's poor and about 78% think it's adequate to good, which is kind of disappointing. We currently run the route servers on open BGPD platform and we think we can enhance the stability if we introduce another implementation for which we chose BIRD and we will, again, do that on two different locations on two servers.
On a question if people were interested to peer again with this other pair of route servers, 90% say yes so there is definitely interest to do that and we will do that somewhere in this year or so.
And then that you will stuff will be officially launched in the, what we call the more IP meeting which will be held 8 and 9 of June. Part of the meeting, there will be a whole lot of speakers. It will link into the world IPv6 day, and part of it will be the AMS IX technical and general meeting. And that is it.
Any questions? No.
AUDIENCE SPEAKER: From Vienna Internet Exchange. I have a question regarding the SLAs. These now coming with penalties?
HENK STEENMAN: Yes.
AUDIENCE SPEAKER: And the customers have to claim the penalties.
HENK STEENMAN: Has to claim the penalties
AUDIENCE SPEAKER: And the SLAs have to be have a price tag so you still get the contract without SLAs and one with SLAs with higher price?
HENK STEENMAN: That's correct.
AUDIENCE SPEAKER: Thank you.
HENK STEENMAN: Thank you. (Applause)
CHAIR: Next up is Petr Jiran from NIx.CZ.
PETR JIRAN: Good morning, ladies and gentlemen. My name is Petr Jiran, I am from Prague Internet Exchange, which is located in Czech Republic, and I would like you present our evolution steps and the focus to renumbering.
We can talk about revolution steps, too, because these changes were never done in our exchange before, so we can call it two revolution steps.
First was topology migration last year which I was presented last meeting, and it was moving from ring to virtualised topology but today I would like to focus on the second step, which is IPv4 peering segment renumbering. It's two month old so we did it before two months ago. And you can see we changed our old peering segment addresses /24 to completely new address prefix, /22.
But first, what is NIx.CZ now? We are in Prague, we have four locations, we are running virtualised dual star infrastructure, mainly Cisco equipment, we have two route servers, BIRD and Quaga. We have 83 members, 22 customers, we have 6 TLD operators, altogether is it 168 connected ports with capacity of 770 gig, our peak traffic from 172 gig and IPv6 peak traffic about 351 Meg.
Let's go back to our renumbering process. So what was our motivation for renumbering:
We have about 60% of IPv4 addresses were used, so we want to have a bigger address space for future growth, so we have to do some change.
So, what were our needs and solutions:
So we have to renumber because we have no possibility to extend mask only, because the upper and lower prefixes were already assigned.
We have to find optimal renumbering process. Wave choice of liberal or strict process, and what does it mean. For example, liberal process is when we say, OK members, you have one month and it's up and due when and how you renumber. (To you) and strict process is OK, guys, we have one day exact date for renumbering and we want to do it at the one time.
Next we have to find optimal coordination process. What is right timing, because some of our members are not from Czech Republic and have a different time zones and so on and so on.
And of course, these process should be feasible for everyone because everybody use different hardware and their networks are smaller or bigger and there are many differences. And of course, we are we want to renumber IPv4 so we want no impact on IPv6 traffic.
So what we do, what were our solutions:
We announced this plan to our members many times on our VGs. So I think the first talk about it was one and a half years ago. We did a special members' VG to readdressing issue. We took members' proposals to, so the process after that was the idea of our members, not ours, idea. We did some configuration tests like BGP sessions on secondary IP addresses, on the sub interfaces, and so on. And of course, we announced our perhaps to our mailing lists.
We do some recommendations for smooth IPv4 peering addresses migration; for example, better way is to operate two independent connections to our exchange, or to use route servers or use IPv6.
So, what was the our renumbering process. So we decided to take a strict process in one day, so we called this day "D day," and this "D day" was selected on the 16th of March 2011, between 2:00 to 4:00 in the morning, so again, we choose restrict readdressing process. This date was announced three months in advance, so every member and customer has enough time to announce this process to their customers, and so on. And to be prepared for it.
And of course, we choose morning hours because there is the lowest traffic and if something goes wrong, we have a time to fix it. What we have to do with the renumbering: We have to change only the first three bytes of the old IPv4 address. The last byte remains. So, for example, if we have a customer C Z nick, it's top level domain operator in the Czech Republic, they have old IP address, 194.50 .100.3 and after that they have new IP address 91.210.16.3, so you can see it was for everybody in the exchange, the same.
So the start of the D day was at 2:00 in the morning and we started with a renumbering of our route server 1, which is Quaga. We only killed the process and start new process with new configuration and made change on the interface of the server so there were no problems with it. At the same time, at 2:00, our customers start to renumber but, at this time, should start only these customers or members which are due homed or have two connections, has two IP addresses, and they should renumber only at addresses on the routers with lowest IPv4 address, so, for example, NIC.CZ we have two routers with last byte 245 and 246, so we have to renumber only the number with 245 in the first step. The second router will be was renumbered in the other step.
So next, at 3:00 in the morning we renumbered route server 2, which is BIRD. There was no problems with it because we started second domain or second instance of it with new configuration so we were running two instances of BIRD and there was no problem and it was behaviour, like Quagga or better thing.
And at the same time, at 3:00, the whole renumbering starts where all entities or all members and customers with only one IP address should renumber and remain routers of the dual homed customers should be renumbered, too.
So, of course, it was not ideal and some of our members or customers couldn't do that renumbering at the time, so we have one week period till completely end of this renumbering process. And after that, we wanted to apply ACLs to old IP address to completely remove this prefix from our exchange. But on the D day, we renumbered about 90% of all peerings, so I think it was succeed.
Of course, the main work wasn't on the side of NIC.CZ team; it was mainly the work of our customers or members so because they have to change the configurations and BGP sessions and so on, so we wanted to support them, somehow, so NIC.CZ do mail and context support so we were ready for mail questions and we have to put together all contacts of responsible people who will do this renumbering so every of our members, member and customer knows who will do the renumbering and could contact him and so on.
Of course, the team NIC.CZ team was on the phone at the D day, because five calls at night and it was pretty funny because these calls were not so hard and I can show you some examples of, for example, example one, one is calling and we say say yes, hello, and that was all. Our second example: "Hello, NIC.CZ, I have a problem, I have already renumbered and I don't receive so many prefixes from your route server." So OK, it's not a problem because not all route servers clients are already renumbered. So such calls, or the last example, the funiest one "hello, NIC.CZ." Hi, guys, what you are doing I have renumbered already but my BGP session are still down." "That is strange. What are you doing exactly?" "Oh, wait." Still, nothing. How many times I have? So, OK, oh Hi, sorry, I was wrong, I was configuring another interface." So such calls, so you can see that we have no big problems in the night, so I want to thank all for all customers and members, operators, for great work. Of course, we support this on the intranet, too. We have a special table on our web. When you can find new or old IP addresses, ASNs, contacts you can you can write comments, I am on the toilet, I will be already I will renumber in ten minutes or in two days, and so on. You can change your states. You can see, for example, if you have already renumbered, you have a green line; if you have a problem, you have a red box there, so you can change your states and everybody could see the whole state of renumbering, so I think this application was good because it reduced the communication between customers and members.
And that is all about renumbering. And what are other news:
We cancelled our initial customer set up fee. We are now providing standard trance receivers like SR and LR, and we are turning 15 years old this year.
What are our future plans:
Of course, we need to build up our network, a band of members and traffic growth, we want to do route servers benchmark between BIRD, Cisco, open BGPD and Quagga. We want to test new hardware, 40 gig and 100 gig interface, new fee few test IPv4 and IPv6 features. So thank you very much and you have a question?
CHAIR: Thank you. Any questions? No. OK. Thank you again.
(Applause)
CHAIR: Next is Keith who is going to talk about some initiatives that ISC are doing in the route service base.
KEITH MITCHELL: Good morning. This is a relatively quick presentation, it's really just a heads up about what we are doing, and call for input and feedback and maybe even some help in resources.
We have been asked by a major funding party to build an open source routing forum that will basically allow some support for a number of the open source route server projects, open source routing implementation which a lot of exchange operators use as route servers. Some of these are in better shape than others. I know that as route server operators, some of you have tried some of these and don't like them and have switched to others; it it would be nice to and help the projects that aren't doing so well. One of the things need help with is testing, some better software development methodologies and some engineer resource to fix the boring bugs, basically we would like to up the game of the routing source implementations.
Why invest in this: Well, there is always more work to be done and open source platforms are generally the place to do the experimental work. There isn't enough research done into routing, open source routing projects are basically allowing new ideas to be implemented. And when you are running route servers you tend to prefer to do that in open source platforms rather than running it on embedded router platform. So I hope, I don't know, I see a lot of Macs out there but I hope I am preaching with the sense of hope, so...
Background: The various things ISC does: This fits into the open source part of our mission. You are very familiar with BIND, demoed in the DNS Working Group as I speak, DHCP, after transition stuff, so we are basically just adding routing code to this.
One of the things that maybe isn't so well understood about ISC is the way we develop open source code. And it's not quite your usual traditional open source community model where anybody can contribute. Rather, what we do is get resources from the people that we develop the software with. We have been doing a lot of work recently in improving the quality and the methodology that we use to develop that on a more professional basis because we certainly know that has needed some attention. And then the software goes out the door and it gets used by the various customers that may be pay for support contracts or foreign memberships or put into their appliances. Sorry, this is the marketing slide. But essentially, it's about making the software better.
So, we have a public service approach here. Essentially, we are going to dedicate some staff, we have a programme manager, Paul has been transferred to this project already. We are currently hiring for a test engineer who will drive a lot of the testing efforts and the Q A initiatives. We are also planning eventually to hire to do the work on fixing the nasty little bugs in the routing code. And we built the test bed. At this moment this is doing relatively simple build tests but we want to add other units, that will improve that. And that way, you get code which is tested and actually has some chance of working in a live exchange environment. And there will be calls and meetings.
So, why am I talking to you? Well, as I say, I know a lot of you use open source routing implementations for your route servers. How can we help you with that? How can it help your operations? Do you have a wish list of top three things you would like to see fixed about the various implementations you are using? Some are better supported than others and this is not in any way a criticism of any of these projects; rather, it's an attempt to help things along. At the moment we are doing an incubation which means that we are receiving what we call organisational membership. You can now sign up to ISC as a member and sponsor us, and that money goes towards subsidising projects like this as a public services so if you are interested talk to us and donations in kind in terms of equipment or personal resources are extremely welcome and that is it. I am happy to take any questions or feedback.
CHAIR: Any questions for Keith? No. Thank you very much, Keith.
KEITH MITCHELL: Thanks.
(Applause)
CHAIR: Despite starting a little bit late, we do have a ten minute slot left after Job's talk if anybody has a lit thing in talk they would like to do. If you do upload the slides to ROSIE. We have a one minute talk. Any other takers? If you do, put the slides up on ROSIE and catch us after.
JOB SNIJDERS: Good afternoon, I am Job Snijders and together with some people we recently started a project called prefix serves and I would like to share some information on that project.
It's about route servers. I think most of you will agree that route servers have been an incredible feature or advantage for Internet Exchanges. You report somebody is useful from day one, and they are becoming increasingly important because people are increasingly lazy when it comes to peering sessions, I think, and with route servers, this is a rough estimate; I have no hard numbers, but I think at AMS IX, if the both route servers would fill you might loose about 100 big bits maybe more, but they haven't filled recently, both of them, so I don't know it for sure. But in that area, there is a lot of development that can be done. Everybody kind of makes their own route server solution and not all of them are perfect; some have some good ideas in one area but not in another. And what I have noticed is, currently if you have 32 bit ASN, it's problematic. Most IXPs use BGP communities to control what goes where and with 32 bit ASN it doesn't fit in the regular.
So given these problems, or lack of features, I thought that is okay we can try to improve, see if we can make the perfect set up and I cannot solve all problems; for instance, path hiding, I am going to hand that over to the IETF, I am not start enough to do that but there are some things that we can do. And one of the things I would like to emphasise is when doing route servers, you need some kind of out of bounds management system. RPSL or some interface to control what goes where and why, is too limited; it's not built to support route servers in a sensible way so you need to work around that, a web interface is probably the simplest thing for everybody. The napping between autonomous system numbers and AS sets and some identifier currently, most route servers, you have the front of a BGP community which is 16 bits and the later part that is used to sorry, I am stuttering a little bit with 32 bits ASN, it doesn't fit in BGP communities as we do it nowadays. What I have noticed is a lot of tier two or transit providers they don't want their prefixes to go to their customers so they want the traffic to flow over their paid connections but touching 80 BGP communities to a prefix is also unpractical and every time you get a new contract with a customer and you have to change something at every point your peering with a route server it's annoying, so we thought as we make a mapping in the web interface you can say this is mapped to that number and that number you can use in the BGP communities to control what goes where so it means that if you update your AS certificate, the route server will follow within two or three hours, and you never have to change anything at the session with the route server. Making the route servers aware of what your policy is when it comes to importing, is important. Most route server implementations currently only look at the reannouncements but they don't take into account what the participant might accept, and with path hiding you want to make sure that you send prefixes that the participant will actually accept, so if there are five options and you know that two of them are not accepted by the participant anyway, you don't have to offer them. RPSL, is, in my opinion, a nice tool describe what the black box of the route server is. An RPSL, the config you put in, the Internet routing registry, it can describe if you put this BGP community on a prefix, then it will go down that way and this will happen with it, but I don't think that, currently, it's a useful method to steer what the route server will do. And strict RPSL filtering, a lot of route servers already do it, but it's a good way to prevent chaos.
So, prefix servers, what we plan on doing is, well, will be at Internet Exchanges. You can peer with us, that is free. We will give you all the nice, the web interface and feedback through that and to get break even, we will do some premium services on top of it, because given the fact that I have a direct BGP session with you, I can notify you if I see weird things. If half of your prefixes suddenly disappear it's usually to to get an e mail from outside. If you are sending BGP updates real past, maybe 1,000 per minute, maybe something is flapping in your core you might not have noticed, I can detect that. With RPKI it would be nice if you prefixes, if you sign them but something goes wrong and it's not valid, what you did, and an alert is useful, so in that area, alerting and monitoring will try to monitorise this a little bit.
And we can offer it white lab on Internet Exchanges so if you want your own logo in web interface, that's possible.
Well, enough with the commerce bluff. We also started a route server operator mailing list and I would invite you people to please join. It is open, it is not vendor specific. What we try to achieve with the list is develop some generic methods of dealing with route servers that everybody uses, so if we agree as a community or part of it, that mapping AS sets and AS numbers to numbers is a good way of doing things, that can come out of that list but please share and make it searchable in Google, it's useful for people.
I think that is the end of it. Are there any questions?
AUDIENCE SPEAKER: Blake Willis with L33 networks. Have you thought about an addition to the web interface that you proposed, have you thought about also making an API available between behind the web interface to give maybe somebody that hasn't automated update database something a bit more automated and hooks into this. Thanks?
JOB SNIJDERS: Well, if people want that, yeah, why not? I am not sure, APIs are usually a good thing but if you are updating the AS set and then you need to do second change somewhere else through the API, it could be twice the work that is necessary, so but we will see. I mean, it's useful, it could be useful I think if policy is enforced as fast as possible so looking at the Internet routing registry every hour is preferably over 24 hours and an API could be maybe a nice method of kick the script and do it now. Thank you for the suggestion.
AUDIENCE SPEAKER: I am from Greek Research and Educational Network and Greek Internet Exchange. So, at some point you mentioned RPSL. Where is this RPSL will be written? I mean, is it in the web interface that you mention or in the Autonam object of the peer?
JOB SNIJDERS: Well, what comes out of the route server management tool is RPSL that describes in route servers out num what the route server does but what a participant does in his out num, that is up to the customer.
AUDIENCE SPEAKER: I agree, I absolutely agree with you, and this is what I wanted to stress: That you shouldn't request from the customer to change its own auto num.
JOB SNIJDERS: No.
AUDIENCE SPEAKER: Because this is the case in some exchanges and it is very weird because if a customer like we do, depend heavily on RPSL for its own routing policy, then the exchange should not ask the customer to adapt its routing policy to what they believe is correct, for example we had we have some big exchanges and they couldn't pass our RPSL, which was correct and was representing exactly what were supposed to do but we have some extra argument, but MED and such stuff so we are asked to adapt our RPSL for this and that was really bad and, we had our policy to make it please, it is good, use RPSL.
JOB SNIJDERS: RPSL, it's very nice if people do it, but I don't want to have a hard dependency on it because the chances of something going wrong or people making not understanding the syntax of RPSL and accidentally, they use it wrong, it's too complicated to really rely on it lightly so it's a nice addition and use RPSL, I encourage people, from a route server operator point of view I would not trust it super much. Does that make sense?
AUDIENCE SPEAKER: Absolutely. By the way, I think RPSL is very limited.
JOB SNIJDERS: Yes, I agree.
AUDIENCE SPEAKER: So there is need for some other way to describe routing policies. For this purpose, it might be for the purpose of what you describe, it might be but generally, I don't think that this is
JOB SNIJDERS: The problem that route servers have with RPSL is RPSL is used to describe what you will do with your direct neighbours, and you cannot really describe in RPSL something that should happen a hop away and that is actually needed to, in the route server context.
AUDIENCE SPEAKER: OK. Thank you.
AUDIENCE SPEAKER: I have a question from Sergio Rajos: Is BFD, by directional forwarding detection suitable for route servers, any plan to implement it?
JOB SNIJDERS: If you talk BFD with the route server, that is useful, but what actually is needed and other people like David Freeman from Clarinet and other people worked on that, it would be nice if a route server can redistribute information that two distribute should set up a BFT session with each other, if it's available on the market I would use such a thing but I wouldn't know currently how to do that in a sensible way.
AUDIENCE SPEAKER: AMIX: Unlike what you state on your website the AMS IX are perfectly capable of running AT 32.
JOB SNIJDERS: Could you explain to me how it works with the BGP communities, then?
AUDIENCE SPEAKER: We don't use BGP communities.
JOB SNIJDERS: OK, sorry.
CHAIR: Any more questions? OK. Thanks, Job.
(Applause)
Next up is Andrei, who has got a lightning one minute talk on something and Serge is going to do EURO IX update so pulling that forward from Friday.
Andrei: Thank you very much. I am talking to you now as author of routing demon BIRD. The day before yesterday I just packed and raised a new version which is version 131 and it's sort of final version of our first part of the development, so we implemented all the features we wanted to and we are somehow satisfied with the state of the demon now and that is why we would like to ask for input from the community which way the development of BIRD should go, so if you have some if you are missing something in BIRD, now is the right time to send us e mail or some comment or catch me here on the RIPE conference and talk about the new features you would like to see to be implemented at BIRD. That is basely all input from community. Any questions?
KURTIS LINDQVIST: I would like to have ISI, please.
CHAIR: Apart from any other psychopathic comments? Any other questions? OK. Thank you, Andrei.
Andrei: Thank you very much.
(Applause)
Serge: There is a this is special bit before. My name is Serge from the European Internet Exchange exchange association, EURO IX. Some of you may or may not know that EURO IX came out of the EIX Working Group, a few of got together and thought we want our own association and the reason I am telling you that is because, and most of you are going to hate me because it's just before lunch and I figure most of you are awake and it's going to be an interactive session because everybody knows I love studio participation I meant to say foreign participation. Almost to the day EURO IX is ten years old so we are all going to sing happy birthday to EURO IX. Even if I sing it on my own. Happy birthday to you, happy birthday to you, happy birthday dear EURO IX, happy birthday to you. Hip hip hooray. That sort of worked. Half of the audience. In Dutch, no, we are not going to do that.
So as I said, what did I say? How do I move this? Is there a I thought I would give you a quick overview of the European IXP scene today. There is 130 IXPs that I know of that are operating and still running. I showed you the August 2009 figures so this is about last 18 months how much this has moved. Most of the countries in Europe have now got an IXP, I will talk about that in the next slide. There is a around 6,000 participants at the IXPs and around 3,300 of them have unique ASN so there is quite a number, at least 1,000 that peer at two or more exchanges and a lot that are peering at a lot than two, 44 that peer at more than 10 IXPs in Europe. All of these are increasing and as a Andy was talking about, there does seem to be a need because the IXPs are getting bigger and more participants coming along and more IXPs are showing up.
This is from a slide from the presentation that I gave in, at the last meeting in Rome, that is it. These five countries didn't have IXPs at the time and we, not only because we got together with PCH, RIPE and MENOG to do a study at one of the MENOG meetings in Istanbul but for various reasons these countries now have either got an IXP or on their way. The only one I am not too sure is Macedonia, but Albania is, or is very close, Bosnia, Kosovo and Serbia. Anybody from Macedonia? No. OK. But we are doing more of this stuff. There is going to be a quick plug for the RIPE regional meeting in Dubrovnik which is 7 to 9 September, we will be doing more IXP stuff so if you know anyone interested in that region that wants to know more about IXPs, tell them to head there.
Traffic, it's still increasing, but it is slowing down. Looking back at the years, the 12 month increase used to be around 60% or more. For the last few years dropped down to about 50%, now, I am presenting figures mid to high 40% so it is slowing down. Having said that, the aggregate IXP peak traffic in Europe increased by almost two terabits per second over the last 12 months.
One something that is interesting to note and is that the, if you look at this increase here, or the months here, you will see it's very flat from about March, April on and it drops down in summer as usual, but this, the bit where it starts dropping is becoming earlier, it used to be around June, pulled back to May and you will see this year, I don't know if it's anything to do with a good weather that a lot of the countries that have been having, that seems to play an influence on the amount of traffic, as soon as the weather get better the traffic goes down and we have have been having some pretty amazing weather but there has been a drop in traffic over the last couple of months and that is probably going to continue through the summer, I would suggest.
It's hard to really put a projection in place but I would say by 2015 we will probably be looking at about 60 terabits of traffic across Europe at the IXPs. It's peak time which is around 10:00 CET, CST. For those people that are interested in route servers, this is the breakdown of the route servers at EURO IX community, BIRD and Quagga seem to be the most popular.
I actually meant to update this. I am now getting more and more IPv6 information, the information of participants at the IXPs that at least have an IPv6 address, whether they are peering with that or not, I can't tell, so I will try and provide some more information. I am asking more of the IXPs, using sFlow to provide me from IPv6 stats. From the few that do, I can tell you that the total percentage of IPv6 traffic that is being exchanged at the IXPs is still very, very low. But more to come.
So quick update for the EURO IX affiliation: We have now got 59 affiliates, which is pretty good, over the last ten years, when we started with a handful of seven IXPs. Most of the countries in Europe are now being covered, at least the ones IXPs and quite a few now Africa, Asia and US of course, as well as Brazil. Since the last RIPE meeting, these are the new IXPs that have come on board. Both European and further afield, and TREX right at the bottom in the larger type, ,
I have done that because they became a member of EURO IX today so make our 59th member, they will be presenting on Friday, the second or other the other IXP in Finland.
Some of this membership increase is due to the fact that we now have a new membership class and that is a remote associate member, anyone, any IXP anywhere in the world can become a remote member of EURO IX. Probably want to get involved in a mailing list and some of our on line resources that we have at a reduced fee so if you are interested in that, come and have a chat with me. Forums, this is where we get all of our IXPs, almost all, to come together. We have a really good turnout. 42 came to the last meeting in Oslo; we are expecting about the same number in Catania on the 30th and 31st of May. If you have an IXP and represent one and are interested in coming, even if you are not a member of EURO IX, come and have a chat with me and I will explain the possibilities about that.
One last but very important bit of news: Our staff is growing, as our membership gross. We have a couple of web designers and we now also have a administrative assistant and I will ask her to stand up. You can ask her any questions about EURO IX. I think that is about it. I have made it. Any questions? No.
CHAIR: None at all?
Serge: One more time with the happy birthday.
CHAIR: I thought there was a no singing rule. Thank you, Serge.
(Applause).
That concludes the morning's first morning session for EURO IX sorry, EIX at RIPE 62. I would like to big thanks to our scribes, transcriber and audio and getting everything with the hotel wiring. Looking forward to seeing you at 9:30 on Friday morning and I hope there is not too answer it hangovers. Thank you.