These are unedited transcripts and may contain errors.

---

Notice: Use of undefined constant steno - assumed 'steno' in /var/www/html/ripe-60/steno-transcripts.php on line 24




EIX session, 6th May, 2010: 4 p.m..

CHAIR: Welcome back to EIX, session number 2 of the day. Hands up if you are more awake for the afternoon session than you were for the morning session? There is a few.

Okay. There is a very slight change to the running order for the afternoon session, we are going to continue with the route server mini workshop is the first item. Then we are going to do Vincent's commercial presentation on challenges for IXPs then we are going to do the WDM talk, the agenda has moved slightly but everything else will be as planned hopefully.

The first presentation is a route server mini workshop, and we are going to kick this off with Andy Philip from the host organisation, net.cz and he is going to update us on the BIRD project.

ONDREJ FILIP: Good afternoon everyone. Could you help me a little bit. Is there anyone in the room who honestly doesn't nor what BIRD is actually.

I mean the Internet routing BIRD, that's not the flying things. That's great. I hope you would answer that way because it will save us a little time.

So, okay, I really three or four slides just a quick overview of what BIRD is. It's an Internet routing demon, it implements RIPE BGP, it's the free licence GP L, it supports some advanced BGP features which are probably the most relevant to you IXP guys. It's highly flexible and that's if, I say highly, I mean really highly that's mainly pause of the protocol pipe which has some special features that help us to create architecture inside BIRD. I'll show you how BIRD can be configured or how can look Internet structure of that. It has a powerful configuration and as well a very powerful filtering language. That's one of the key features. It has an automatic configuration, that means that although is reads configuration from a configure file F you update a configure file and send a comment to BIRD that it should reconfigure, it is able to find the changes so it just ?? changes exactly the things that were affected so it doesn't affect the run of protocols that were not changed in the configuration.

And it's one of the products of CZ dot NIC labs, the research and development part of the cheque registry.

So, the design I have promised to explain. BIRD can be configured in the way that it can have a multiple routing tables. Those routing tables can be addressing ionising operating system routing tables or can be just let independently and those routing tables are interconnected which the pipe protocols. So, BIRD can be configured like a multi?router, a multiple route servers, multiple refractors on a single machine, so it's highly flexible how you connect those tables and what filters you apply among them. So that's something that's very, very handy for Internet Exchange point basically.

Just a flavour of the filtering language. As you can see, it looks like almost C programme, although we don't support for example four cycles or something like this. But still we can have a function, we can have variables in that and this is very handy especially for very complicated filtering. The example that is shown on the screen it's actually the community based filter and at Internet Exchange route server, so as you can see, the same thing that, if you configured in a Quagga takes thousands of lines for each peer. This is all because we can have functions and we can use variables in those functions. And the second part of the configuration is just, it's a definition of a BGP instance to some peer.

Another, really nice feature is the other filters, because they are configured a different way, they are not just like prefix per line or something like that, that we are used from Cisco, they can be like all defined in a single line and that helps BIRD, because it can take all the filter and create a binary tree from either prefix list or ought Monday system numbers list or whatever you want to filter and you don't go in linear time, but you can be in algorithm time so much faster in the filtering. So that's also one quite unique feet of the Doe Monday.

This is the key part for Internet Exchange points. That's the problem most can set up for Internet Exchange points although there are some exceptions and that is that you run a multiple routing table per client, which usually could be ?? they are actually more ways, either you can have a single routing table per client or you can have a single routing table for BGP session, so I chose example here you are using NIC CZ in the Prague Internet Exchange points. So, you have multiple routing tables for multiple clients. Those clients are connected to a routing table. They are now importing filters so you can see what those guys are sending to you. But if you want to resend those routes like from the routing table that is named T 111 to the Master routing table, they go through a special pipe protocol and they are inbound filters applied to you just allow at the moment to send exactly the traffic that you want them to send or that they may be configured in IRR database or something like that and those are stored in the master routing table and then you may want to export them back so through the same pipe or in of course, in another routing table, all those routes are exported and you can apply like, for example, the community base filters that I showed you in the beginning. So I hope it didn't sound too complicated, but at least you who are familiar with route servers, I hope you know what I am talking about.

So that's one of the ways how you can set up BIRD. That's one of the ways that, you know, it can serve you. And it's mainly because it has the flexibility with all the pipes and all the stuff I was talking about.

And in Lisbon, when I had a presentation for the big Plenary about BIRD, I think I announced just two Internet Exchange points that were using BIRD at the time and that was ?? who was the bravest exchange point who started BIRD, using BIRD as a route server and since that time, I don't think ?? nothing changed, they didn't report any crashes. And they actually use two route servers, BIRD and OpenBGP so they have dual to set up, I really recommend to people, to have some ?? and those guys will help us a lot with the debugging of bugs

The second exchange point that started to use BIRD was basically NIX dot CZ, we also use a second different implementation so we use BIRD on Linux and Quagga on BSD and again BIRD seems to be pretty stable. We have about 8 thousand prefixes and the number of consumption is really invisible in current system. So it's like mega bites of memory.

And here are the new guys had a that started to use BIRD recently. So after the Lisbon meeting. First of them was LINX, those people have a very careful in testing, they sent us a lot of bug reports and I thank you them very much. They also use BIRD. They have like 200 BGP session with roughly about 50,000 IPv4 prefixes. And they use also the BGP communities for choosing to whom export the route and so on. So, basically the same setup as I introduced in the beginning.

So they are the first really by guys that started to use T although I have to mention we are not so small, we are 6 in Europe. Another big Internet Exchange point that started to use BIRD was Moscow Internet Exchange point, and again, every implementation was very helpful back to us because all those guys found something that we should improve or fix. So they also reported one back to us that was related to some actually back in Cisco on the other hand, Cisco somehow reacted unexpectedly and were crushed that was definitive bugging BIRD as well. So we fix this had thing. And they also asked for some additional feature requests. Mainly because they wanted to implement a look glass. In the Lisbon meeting, I spoke about the problem that they still lack of tools beyond BIRD and looking glass was one thing I mentioned, so now it's done by Russians and I know that they are sharing this tool so if you are interested, just write, I am pretty sure they will help you with that. And also they have like 300 members and 12 thousand prefixes and they use ASN 32 is they had to deal with that strange way of numbering autonomous system.

Another quite large implementation was DE?CIX in Germany. Germans and, you know, they are punctual people so I think they have probably the most in the way of filtering that they could possibly implement, but it works, it works perfectly mostly. So, they have about close to 400 BGP sessions. The BIRD takes like 3 .5 gig of memory, but works stable and we don't have any bug reports since the implementation from them. So I hope they will confirm it's still running smoothly. Again they also use ASN 32 and also use it for IPv6, but many use it for IPv6 although it's not mentioned.

Last but not least, I don't think I need to spend much time on that because I am pretty sure there will be another presentation after me about VIX so VIX is another example and they actually use completely different architecture of the routing demon than the others, so I will let this to them, I will not explain it further but it will probably show you the flexibility and variability of the demon.

And I just spoke about the European exchange points so one from America, PA I X, they don't use the community based exporting, they use just a single web. On the other hand they run BIRD in a lot of places, I am not sure if the list is complete, but you can see they are exchange points done in the east coast and also on the west coast. They they use it in a lot of places and they have some sort of central configuration that sends all the configures to those places.

So, that's an example for the one buying guy using BIRD and there are some other, maybe could stand up and tell us that he or she is also using BIRD but I know about anyone Menap E6, there may be an a couple of others. And I know that we also are disgussing it with one of the Asian big guys, that's J P Nap.

The new features since my September presentation. We have OS PF v? 3, I know you are exchange point guys. But trust me I know some people were very happy with that. We implemented some minor features for BGP like the passive option or we improved filtering a lot. I just speeded up and also adding new features like community based filtering and so on. Because some people started to implement looking glass, we changed the common light interface, so it can be read only, so it will not, in case your script has some problem, it will not destroy your route server sore no one can destroy T we showed richer show command mainly to show more things about the BGP. How the session was negotiated. What the other side requested and so on. So that one is improved a lot.
We implemented some new RFCs like 0554 and 2918 route refresh and preferring of the other routes. Also we implemented M RT dumping. It's just for BGP currently but it dumps every evens that happens on BGP sessions so it's also used by some guys. There is a lot of other minor things, basically all the protocols are improved and we also touched some internal things that would be quite complicated to explain, but those are the main things that that changed since my last presentation at RIPE meeting.

So, that's basically all about the history, what has happened. And now something about future. Most important and great thing we will have a new web page soon. I hope we could manage it at the RIPE. But too busy. We will work probably on the documentation more because some people say that the configuration language is really weird. It's really noggin Tuesday tif and people ask for more examples, so we will probably make the section just examples of configuration. We would like to implement IPv6 route advertisement. There is a reason BIRD is used in very tiny devices like all those modems from any Taiwan manufacturer you have at home. In those devices there is space so you can just install BIRD and also every DVD demon for example and that's also the reason for making common light interface because those guys don't have time for libraries that are necessary nor our common light interface which is slip history and so on.

Our long term plan is to develop route planning permission dampening and also one thing we are pretty sure we'll make is a port to Solaris whenever I said some people say why err doing crazy things? Basically, it's because we use BIRD and that have the main purpose we started to, that was on for DNS Anycasting cloud at CeaserNic and some of the missions are using Solaris, so we need to have BIRD there as well. Important thing is really depends on you if you have some feature request, if you see some weaknesses that need to be fixed, just let us know and I am I am pretty sure we'll tell you if that's feasible or not.

So I am at the end of my presentation. I basically I just wanted to show you that BIRD is flying, that BIRD is us autoed by many Internet Exchange points, that it's pretty stable, deployed by also the biggest guys and that it can be flexible too and tailored to your needs and if you are using it, just please let us know if you have some feedback we will be more than happy to hear from you and although we are very open to get some feature requests, so if you need something, really let us know. Many people did send and now their problems are fixed. So thank you very much. And do you have any questions?

CHAIR: Any questions? Maybe someone will have a question after they see a user example from VIX.

AUDIENCE SPEAKER: Jerome Durand: I am wondering we had an interesting presentation on Monday from Randy Bush about how a router could check the RPKI infrastructure with the protocol between the router and a cache. I am wondering, and I think that Internet Exchange is the place where we have to work in that field, you know, to secure the routing. Are you working on this kind of protocol in BIRD?

Answer: No honestly, just after we presentation with Randy, and re the key developer of BIRD and we spoke about the thing and we, you know, agreed that we should work on that but there are nos were plans yet.

CHAIR: Thank you. That was a good question and thank you for the presentation.
(Applause)
Next up we have Harald again from VIX. Many people in the room, many exchange points in the room use BIRD and filter on communities and other examples, but Harald has a very different way and would like to show us now.

HARALD MICHL: Hello. It's because this will be a split brain presentation for us to follow a little bit of theory about how we implemented our BIRD implementation and afterwards with the friendly permission of myself as operator of the academic network of Austria I will somehow you how it looks like if you are an ISP and connected to the exchange point and use this interface.

We built a router at VIX. Well there are big advantages also, Lisa mentioned this on Monday already so I will not spend so much time on that and rather have a look an how we implemented it. But currently there are very many similar implementations and on the Ray mentioned things like main routing table and community control things, and normally, as I mentioned in my presentation this morning, we look at other things and copied and adapted it to meet our needs and use it. In this case we thought we will want to go a different way.

We do not want to reinvent the wheel but to make it a little bit better or round errand the goal was to make a route server that is self explaining and usable even for those guys wearing ties. So it should be not only understandable for technicians but also for all other people that are able to use a browser.

A little bit of history: We started semi?production on April the 19th, so it's only two weeks apart, and still I have to correct on the Ray, it's 25% actually participating so it's around 26 participants that already use these within two weeks so we are very happy about that. It is running on BIRD routing demon and we do not have dedicated machines for that, but we use virtualised environment and it's already and re mentioned there it was a bug with timing issues, but everything is fixed.

We have had two sites at VIX and we have, on each site, one implementation and one demon running for one protocol. So two IPv4 and two IPv6 running.

Instead of other implementations we do not have a global RIB, we only have global ribs per peers and we use the pipe protocols that and re mentioned to interconnect these ribs and only where they are defined you want exchange routes there is a pipe established and therefore we do not need any filtering because if both parties agree won a filtering there is a pipe and if there is no agreeing there is to pipe. On the other hand, as I mentioned we have two sites and of course we want to keep the inter site traffic as low as possible. Our database knows which IP address is on which side and can prefer routes on the same side so that we can control the traffic to be as site local as possible and to have the minimum load as possible on the inter site links. And of course, peering starts only if both parties agree on that.

We decided not to use BGP communities for controlling this thing. We use a simple web interface. First of all because it's just easy to use and on the other hand, you have to establish only once a routing session to the BGP route server and never, ever have to configure or reconfigure your route maps to text the routes with these and that communities. You establish a response. You do the rest on the web interface.

Filters are in place at us as well. Every member can provide two AS sets, one for IPv4 and one for IPv6 and routes are free accordingly to these AS sets and routes that are not within these AS sets but are announced get marked with a special community so that you can filter them afterwards.

We have IPv4 and IPv6 feature equivalence and also I SN 32 is okay. But there is a little thing missing between the web interface and the database, so this is not a technical thing, it will be solved within the next few weeks.

The interface itself, you can set defaults and you can make exceptions per peers. Default can be yes I want to peer or not. And yes I want all routes or only filtered routes. And the exceptions of the peer also includes that you can send configure a prepend to your peer from 0 which is no prepend up to 4. This is the current. If you need 6 we can implement it as well. The interface you see the status of your counterpart.

Here you see a small explanation of it. The green things are ?? the green things are the fibs of the route server. In this example you have four peers, 1, 3, 5 and 6 that use the route server, they have BGP sessions to the route server for instance, and wherever you have a peering configured, there is this green arrows that show that the routes get interchanged and here we have some peers that do not use the route server, they have direct BGP peerings to each other and it's also possible to mix it so you can use the route server for example to peer at these two ASs but have a dedicate highlight BGP session to someone else that's not participating.

Okay. It's new, we do not know something similar, so we need your feedback to improve it or to make it useable. And to give you a feeling how it looks like. I can switch to this live thing ?? I'll show you what we configured here. My password will be later on in the live recordings. I click here on network. Route server IPv4. I am responsible for two ISPs here. I have to select one. If you are only responsible for one there is nothing to select. First of all you have to activate T you can set your password yourself. And afterwards you can set your defaults. You can set the defaults. Peer with all the participants per default, peer or do not peer. In our case we selected peer. And then you can select default prefix import policy. Import only prefixes found in the RIPE DB or import all prefixes. Then you have the sort order for the list that's in the bottom.

Then I get a list of all the peers that are available. First I see, for example, one or two, where there is no peering session in place. Because I explicitly overruled default. I said do not peer and therefore there is a red X because both of them were not our customers and we do not want to peer with them at the exchange point. The others you see that here is always the peer like default and there is a green cheque mark so we know peering is established because the other part also agreed on this peering. We see this part is 12 prefixes in the RIPE DB which is accepted by us, there is also the contact information and the macro this information lies on. There is many he yeses and you will see there quite a big amount of things. Here you will see the the list of those not yet participating. So we hope to get them soon and I want to show you another exception. Here, for example, this here have overruled the default and say first peer and also input all prefixes because Microsoft commonly doesn't reduce the refixes in the RIPE DB. They are going to join this project as well and therefore, we already set this value, but they didn't join it so far so this is currently ?? and okay there is something to do.

On my side, on the top, I can see further information. I can see my own IPv4 prefixes, if I click on here, so these are the prefixes that are registered to me and this is my AS object that is accepted by the route servers and so I can control which prefixes should be marked as good or reduce that from the route server and the others should see it. And to keep my own OUT NUM object up to date, there is a feature that you can get this output that should be copied to the RIPE DB, for my OUT NUM, you have to copy and paste the documentation below will be up to date this is available for IPv4 and IPv6.

So this has been the things.
Any questions?

CHAIR: Do we have any questions? Yes we do.

AUDIENCE SPEAKER: Nick Hilliard:. Not a question, but just a comment. Your policy of not using communities is a good policy for two reasons. First of all, the community based filtering system breaks rather badly with 32?bit ASNs, but also as you scale the route server bigger ?? if you have prior knowledge of what you are routing, filtering configuration is actually going to be, then that means that you can actually cut down on the number of RIBs you need to maintain within your BGP demon. And this reducing the resourcing requirements for your route server software from effectively from N squared internally down to N, which is a huge, huge optmisation, so I would see that in the next couple of years, all of the larger exchanges are going to move away from communities and words to this policy that you are doing. But your system looks very nice.

SPEAKER: May I comment on your comment. There is also another big advantage of not using communities, with the teching routes the special communities to may be announced you can only control the direction from you to the others. You can influence which prefixes are distributed to why, but to dot other way round, cannot select which prefixes you'd like to receive by attacking your routes with communities. You can filter on your boundary but then you might drop a best path and do not get anality net path, as long as the RIB in the route server itself only distributes best path. So it's only bilateral and by direction. It's only if both parties agree a path will be opened. And no path will be opened if there is not consensus on both. I think it's easier to use.

CHAIR: It looks really good, I agree.

AUDIENCE SPEAKER: I have here a question from David Croft. Maybe you have answered that in the beginning but he just joined. Are VIX intending to make this portal available to other IXPs?

HARALD MICHL: If there are other interested in how are we did it, we are willing to share that information, of course.

CHAIR: Thank you very much. Any more questions now? Thank you.
(Applause)
I am sorry, I have had to make another change to the running order because Vince has an urgent appointment shortly. So we are going to do the business models for an IXP and the challenges for an IXP talk from Vincent right now and then we'll won included the mini workshop with the U R X Quagga team.

SPEAKER: Vince: Hi everybody. My name is Vincent rise and I work for interaction. Interaction is an operator of data centres in Europe.

So, I work for Inter EIX, and before that a long time ago I worked as a peering manager and I sat on the board of items AMS?IX for a while as well. Over all these years I have seen Internet Exchange evolve and not evolve and I'd like to do a quick presentation on that. I do apologise I have to run off for a meeting I couldn't escape from. So, here we are.

Basically in this slide you can see all the Internet Exchange, some 18 in total that we partner with all over Europe. It's my primary responsibility to get them in to partner with them once they're in, to help them out in some cases in the further development of their exchange.

So, these are meant as things to consider when starting or growing your own Internet Exchange, it's based on my own experience as I said, no names will be mentioned, of course no examples, including names. But they are actual exchanges and hopefully it will bring questions, maybe not here but internally for your organisations.

So first something a little bit about the foundations of an Internet Exchange. The legal structure, if you like.

We have seen in Europe, since the late 90s, that member base associations has become the norm and this works very well with smaller exchanges. Although, once they start to grow bigger and more issues arise, that process, to take decisions can actually become a bit of a strain on the organisation as well. So you have to consider that very well when you start an exchange.

You also have to consider what's the purpose the some exchanges are very limited in their scope. I think if you would start an exchange today you would not only have to consider what is our purpose today, but also try to imagine a world in ten years, and what your purpose could still be then.

Income: Very important for an exchange. The pricing you set is always an issue. And I have seen it go horribly wrong basically. France is a country as a great example. It's a huge Internet user base, vibrant ISP community, but the Internet Exchange model there was broken and why was it broken? Because, there were multiple exchanges that went, head to head together in a race to the bottom if you like, lowering port fees until at one point there were no port fees at all any more. But that also meant there weren't any means to invest in upgrades for switches or new boards or new network.

So, in the end, it ends with an infrastructure that is less usable for the community. If you are an exchange and you are currently experiencing this free model, because once it's free it's very difficult to get your members to accept to pay for something again, you might consider something that we borrowed from web 2 .5, the freemium model where you get a large user base that comes together for free, is not willing to pay for the services, but you do have larger members that are willing to pay and they would then sort of cross subsidize the free members.

The last question here is I think also an important one. Because I hear a lot that the exchanges think that the members should decide what the price of their ports should be. I don't know. I don't have a say in my gas bill but it's a utility that I need and use very much. If I am left with' digs, I would choose free, but it could mean in ten years that no investments in the utilities infrastructure would mean that my children might not be able to get gas to their house. So, that's just a thought to consider if members should have a say indeed.

Something about products. Obviously these are technical organisations. Do you build a product just because you can or because there is an actual real demand for them? Also, please consider how does this new product affect my members? And also will my members even allow me? As we saw in the foundations, depending on your legal structure, they might not allow you to do one step outside of what you were founded for.

And last but not least also very important, how does it affect my partners? Data centres, as we will see in the next slide, are the partners for exchanges because they house the equipment and they connect the members from them and they might raise and eyebrow with a certain product. So this is also before you just go ahead and launch something, to consider

Then the growth itself an an Internet Exchange, how do you start with two members and how do you become a huge IXP that has a global effect operator of 350, 400 peers connected to your ex exchange?

Well it starts with the basics. That's your entire market size, the data centre itself. Nonetheless UUNET nods that can connect anybody from anywhere really, but most of the exchanges, deploy switches, they connect those switches but they deploy them inside that I say do you tell assenters so that means that eats that in that data centre is all that you can connect theoretically. So why not look at those data centres and try and partner with them. Use them as a channel, if you like, work together with them to develop, have a look at their customer list, ask them how can we go together and make sure that these connect? Because there is an advantage for them. The more interconnected their customers are the less likely they are to leave. So there is a mutual benefit there and most of them will be very willing to help you with that.

I often hear that yes, but well, if we start to do certain actions, directed at sales or marketing we, we are neutral so we have to really include all the other day assenters as well. Well not really. To me I think there is a lot of misconception about the word neutrality for Internet Exchanges, neutrality to me simply means you do not charge the incumbent ISP less than a small hosting company for a port and really it stops there. It ensures that all the members are treated equal and have equal access to a platform that they mutually share.

Neutrality to me is not keeping new business for your exchange away by not partnering more actively with one data centre partner than you would with the other. That's just not common sense. And nobody will blame, I think, an exchange for doing so. There are some examples in Europe where that model works well, and there is other exchanges that struggle with that. To me it seems ?? it's something that a community needs to think about on how to put that together.

If you partner too fast and there is an example of that as well in Europe, and you grow to a huge amount of data centres without actually having a critical mass of members connected, you are less likely to find an agreeable partner in a data centre because they might have subsidised some space and power for you to turn around and see you go to 20 other data centres. Now, if you do that, it just simply dilutes the value of the investment that the data centre just made. But if you partner too little or too slow or both, then you will be limiting your own growth. You will have a problem reaching that critical mass and everybody starts by connecting ISPs that want to connect to a new exchange for free. So, they have a short window of time to reach a critical mass because after six months and you have connected for free that big ISP and he says look, I am here now, but there is no nobody else, I am going to disconnect because I need my port for something that's really interesting. So if you don't make use of that limited window, you are likely to see the end of your exchange coming very close.

And you also need to insulate your exchange against competing products. Mainly IP transit, because everybody keeps saying the cost of IP transit is so low, why should I peer? There is numerous reasons why you should peer other than just saving a bunch of euros. Everybody here I think understands that, but in the value proposition, it doesn't always come across. You can explain why you can peer. You can do it here. You can do it to your members as well. And why they should pay a certain price.

It's alive. Sometimes an exchange grows so fast and so big that it starts to take on a life of itself. Meaning, that port charges accumulate reserves inside an exchange and the technology that's needed to keep growing and keep building out a Newport speeds don't go hand in hand. They don't go in lock step. That means that you build?up a reserve. And with that reserve and all that knowledge that's housing these exchanges, that comes to the natural question: What are we going to do with this? So, that's a conflict immediately because many of them were just simply set up now you perform this function, it's purpose built and do this for me and nothing else. So that makes it difficult for them to jump on some of the business opportunities. Also, and mainly because they have difficulty explaining to their members what the long term benefit tore them is. They might think, no, I am here for peering. I don't want to hear about this experiment or this project. It just takes away money and you should give it back to me because I am paying already too much for my port as it is.

Well, you can reduce your port fees and that's been done here and there in Europe, but you also run a risk with that by diminishing the value of your port again because the less you are asking for your ports, basically the less value you put on it yourself. And it might, indeed, end up in a race to the bottom again.

So, it's an issue for these exchanges on how to unlock this value on the insides, their company or inside their building recollect the technicians, the more commercial people, trying to unlock that value is difficult.

And there we are. The possible conflicts of interest are numerous. They can come from your members, they can come from your partners, they can come from technology and it's interesting to be doing this presentation right after route servers, because basically to me, in technology, I see a very interesting question. The moment you start evolving and developing route servers to the point where they can basically automate, and this is not what's happening now, but who knows in five years, automate the entire process of peering, and really do we need an Internet Exchange? So it's a question and I am the last person probably in this room that will have an answer on that, but it is a question that you, as a community of exchanges, need to be actively involved in. Where can these conflicts come from and how do we deal with them your partners, of course I mentioned a data centre that invests heavily in bringing an Internet Exchange in and then the exchange turns around and starts offering remote connections.

This is an example and it's things to consider because they cause friction or actual conflicts and it's really not necessary. Two choices really: Avoid them, and I don't think that's the case, but manage them early on. Think outside of your own switch park and try to think what the effects are of new technology, new products and services.

And don't be rigid about T don't say cannot do this or we must do this. There are so many interdependences between the data centres, between the members, the ISPs and the exchanges themselves and think of this. As an exchange, you say peering competes with IP transit. But still, you connect IP transit providers to your exchange who buy, spending their peering increase the value of IP transit products, thereby pressuring more on the port prices and the added value of peering itself. Now, that's a hell of a conflict of interest if you think about it. But it's also a way that shows, no, you can go co?exist, you can deal with these things.

Then, some final thoughts.

IXPs, they started out when ISPs came came together to solve that problem they had, latency, the high cost the transit back then. And this was 15 years ago. That's a long time. And it's an extremely long time for an organisation to stand still in terms of core products and service that is they offer. No one company can exist for 15 years, yes, unless they have an monopoly but of course that's not the case here. And it's actually unfair from a members perspective, to keep them in that corner, if you like, because there is an enormous opportunity there because there is knowledge housed in these exchanges and yes, the port fees from the community have also provided reserves there and it would be beneficial to the community long term.

But it needs to be handled well. And if not, there might even be, and it's a bold statement, I realise that, but there might be a threat of extinction by inaction. Technologies change, new platforms, exchanges at lower levels, or lower layers, I should say. There are all these things that an exchange really needs to have a little bit of liberty of looking at and trying to come up with an answer.

So, I think that partners, I think that members should be flexible when it comes to allowing an exchange to evolve to make them better for the next ten years, ask yourselves, what will my exchange look like in ten years? I bet your next question will be: Well my members don't allow this or that. So allowing them to evolve maintains the exchanges and the neutral model which I think in Europe everybody agrees is the right model. And it might not really end up the same way it started, but it's an evolution re process and change in itself is not a bad thing.

So, any questions? I am here today and tomorrow as well. That's my e?mail address or look me up. Thank you.
(Applause)

CHAIR: I really enjoyed that presentation. I think it's the elephant that's been in the room for a while. And talking about it helps.

The next presentation is back to the route server mini workshop for a few minutes. Nick Hilliard is going to present the update from the euro IXP route server virtual Working Group.



NICK HILLIARD: Just a quick update on the euro IXP project to deal with route servers. My name is Nick Hilliard. Thank you very much for having the good grace for listening to me talk today.

Just a brief background. Exchange growth has really grown quite a lot in the past couple of years, and this has been manifested through traffic growth and port count. And this that is created a huge amount of administrative difficulty in terms of maintaining up to date peering relationships with particularly new members of exchanges. For route servers, the route server option provided a really good way of you know getting instantaneous peering with a large number of people.

And until June, 2009, Quagga was effectively the only viable option. There were others available. Quagga implemented multiple ribs which was found to be a requirement when dealing with route servers which required filtering. Unfortunately Quagga had an awful lot of problems in terms of stability and with that in mind, euro IXP has engaged in a project to try and fix this and also to try and encourage the development of other route server stabbings. There were four in particular that were identified. Quagga, BIRD, OpenBGPD and a fourth one which was referred to by a code name Bogart. Unfortunately Bogart came to nothing which was rather sad because it did actually have some potential, it wasn't completely vapoured , it would have been based on an existing highly competent BGP stack which is not generally known in the community.

In terms software development, BIRD and OpenBGPD have been covered very adequately. I am not going to go through BIRD, except so say that it's an exceptionally competent piece of software.

OpenBGPD had a lot of development funded by AMS?IX and that has enabled it to operate as a fully functional route server. Unless you want to do an awful lot of prefix filtering in which case it still doesn't work yet. This can probably be sorted out relatively easily at some stage.

Which leaves Quagga. So, there was a development process and three areas were identified for development stability, threading and optimisation. Obviously, stability was the most important because if you have a couple of hundred clients connecting into a route server, the last thing you want to do is turf them all off when the demon dies. Not very professional when that happens.

So, we have a developer called Chris hall and Chris is doing an if he nominal amount of work on Quagga. There is three main areas which he has settled on. Threading framework, session handling and just generic optimisation. In particular, there were a couple of areas with optimisation, particularly where sessions would drop and then you'd have to go through all of the ribs to find a new route server and withdraw all of the prefixs from those ribs and Chris pro filed that code and found it to be non optimized, shall we say, and has done quite a bit of work in fixing that up.

In terms of outgoing updates, that is now working much better and much faster and it is using a whole lot less CP U and one of the issues that we identified fairly earlier on, which is to say prefix filtering, has also been highly optimized. So there were a couple of other serious problems with Quagga. BGP session handling is a difficult issue I think in any BGP stack, there were two issues there. The first issue in Quagga was that the transport layer was very much tied up with the session layer, which is to say that when you open up a BGP session, you should really be able to, you know, transport addressing L R Is over any sort of transport build it be IPv4 or IPv6 or anything that might be defined in the future A F I. And this wasn't the case in Quagga. The handling of that was a little bit messy, I understand Chris has sorted all that have out now. He has made so many changes to the code it's difficult to review them.

Collision management. When you have two BGP speakers they need to talk to each other but you don't really know who is kind of going to talk to who first and they can actually talk to each other more or less at the same time and then suddenly you are going to find you are actually going to end up with two BGP sessions which is really not what you want. So, the collision management in Quagga needed quite a bit of work, and Chris has said that he has pretty much sorted that out completely. It's a longstanding problem. Not just in Quagga, I believe it affects OpenBGPD as well.

And finally the threading framework.
Quagga, the version of Quagga that we now have in development at euro IXP is threaded. There are three main threads. One of which handles BGP sessions, best path calculations, RIB management, that sort stuff. Another one of which handles the CLI. So you can always log into this system even when it's busy doing other things.

And the third session which was really ?? sorry, the third thread which was really causing a huge amount of trouble was the actual BGP session handling system because you could have operations updating you know hundreds and hundreds of ribs which might take a large number of seconds, and in that time, BGP keep lives wouldn't be sent and the other end would think that peer is gone away and I am going to tear that session down and then all hell will break loose on the system. Anyway that's fixed.

The results are Quagga starts up on very large systems with very large numbers of prefix lists. It doesn't fall over when you smack it. This is good. I have some figures there. 200 clients and 1000 prefixes. I want to mention that a little bit later on.

The CLI always responds. Some of the commands when you type in now, when you, for example, if it's busy doing a RIB update and you type in show I BGP or something like that, it will actually queue the command for display later. But other commands where it doesn't need to query the BGP entry, it will show up immediately.

There is still some memory leakage which we are working on. It hasn't been completely solved. It's quite a large body of codes so that will take a little bit of time.

Future development: Obviously we want to get this rolled into the Quagga, main Quagga tree after a suitable testing, first of all testing within the IXP community and also developer review in the Quagga community. The patches will be released under the current licence, which is GP L. We want to support BGP add path. BGP add path is a massive optimisation in terms of RIB management. It means you can reduce your resourcing requirements within the route server from order N squared down to order N. A huge advantage there.

There is an awful lot of optimisation going on, our scaling go is 100 clients with an average of 5 hundred prefixes each. Now, that may not look like an extraordinary number. It's about three times, two to three times what the larger IXPs are running at the moment. But, for the start?up situation, where you have a route server starting up, all of the clients connect into it and all of them receiving a BGP, sending BGP updates N having them processed and then getting them sent back out again, that process scales, according to the square of the number of clients multiplied by the average number of prefixes. So, if you have 1,000 clients, with 5 hundred prefixes per client that's 5 hundred million updates. Which is a very large number and we want to make sure that Quagga can actually deal with this sensibly. If you think that that's actually a large number, you have to multiply it again by the number of bites per update, which is going to include the prefix, the AS path and then any attributes and you might be talking between 50 and 100 bites or maybe 150 bites per update. So you can see that you are actually talking about very large amounts of data being sent out from a route server.

We also want to establish a competent test environment. There is been an awful lot of work done with a bunch of the people in the route server Working Group, and there are several testing environments there, DE?CIX have a system called hoof prints written in Java. It will really hammer a route server. AMS?IX have a bunch of really useful scripts, which again can be used to hammer route servers and test outputs. And finally, we are using two IXEA protocol testing devices from switch and data, at least Equinix now, the London Internet Exchange. The good thing about this is it's not limited to just Quagga, it can be used to test any of these route servers and obviously any optimisation that is go into the route server code will probably benefit the general BGP stack in the route servers as well.

So, there you go. Any questions?

CHAIR: Any questions for nick? Question, there is a question.

AUDIENCE SPEAKER: Do you have plans for changing or improving the BFD support on Quagga or do you really think that BFDs is a nice feature to use on an IXP?

NICK HILLIARD: The answer is, we haven't really looked at it. BFD support begins to introduce very serious operating system interdependences, now, Quagga, indeed all of the all of the open source BGP stacks are RIB management engine which then sit on top of an operating system and if you are sending out BFD data, that kind of creates ?? that creates difficulties. It can can done. There are patches to make BFD run on Quagga on Linux but they are notity operating system independent in any way and at this moment we are not looking at them. But if you think it's useful, yeah, we could certainly put it down on the wish list.

CHAIR: Okay. Thank you.
(Applause)


SPEAKER: Okay, so this is me again. And this time we are talking about WDM. So, in Stockholm, we have a slightly different fibre situation than many other cities. In practice, we have several providers of fibre, but there is one dominant provider, which is a city company, and because of this the city company can basically deliver fibre to any destination whatsoever. And this is the reason why the NetNod exchange is somewhat different that we actually don't have the ISP equipment in our facilities but the ISP equipment is well, left with with with ISPs wherever in the ISP zone facility or possibly in a co?low somewhere and then we have fibre from the exchanges all around the city to various locations.

We have short fibres that end up in what we call inner city cost, as in the cost for those fibers are lower and then we have outer city fibre, which is a longer fibres, still the same performance obviously but it will be more expensive. Time goes on and co?lows start appearing and suddenly we get a certain concentration of ISPs, of customers in the major co?low facilities and we end up in a point where it's not necessarily a good idea any more to have all those fibres going to the same direction. Enter WDM, sort of clear here. This point is something we reached about two years ago and we took a decision to move in the WDM direction last year.

So, in spite of the fibre cost being something which is included in the connection fee and just passed on, we don't make a profit from it, it's still from sort of assistance perspective, if we look at the ISPs plus the exchange together, it's of course better not to give more money to the outsiders like the fibre companies etc., so this is something that we all win from or gain from.

In the WDM space, there are different alternatives, like C WDM and DWDM, but of course there is also always the option of renegotiating existing contracts, so yes we tried that. It didn't work out. So here we are, WDM.

As it turns out, in spite of C WDM being probably cheaper, we also had to take into account the number of customers, projected expansion growth, distance of fibres, etc., and in the end, we opted to go with the dense option in DWDM.

When we started this, we knew basically nothing about this. We are IP people, we are not Telco people. Some of us still don't know much about this, and that actually includes me personally because I do DNS, but who is counting? I have actually done the DWDM thing and played around with this stuff and done all the damping stuff etc. And I must admit that personally I find it horribly confusing but we have other staff in our facilities that do this all the time now.

So once we found that we had to do the DWDM stuff, we of course had to fit it into all the various operations and monitoring systems that we already employ for the exchanges already, and that means nodules and means plug Inns etc.. (imagine owes) also we have a lot of stuff, so there is a certain complexity management issue that we really need to deal with and of course we have the price component at the bottom line

So we sent out the traditional R F P, we had eight bidders. We had three bidders that were technically feasible and we had two bidders that were, well financially feasible. And in the end we went with the Swedish company called Transmode.

We opted for what is likely to be sort of the simplest possible WDM design that you can think of, which is basically you have a fibre pair between two locations and you just hold together all the various connections, route them point to point over to the other location where you split them in part again. You can, with WDM, do all sorts of fancy stuff across a Metropolitan area to achieve other types of things like redundancy and optimizing for paths between more than two locations. But that wasn't really the problem we were trying to solve. Our problem was that we had exchange in one location, or rather we had exchange in two locations and then we had a whole bunch of customers over here and a whole bunch of customer over there so we wanted to sort of get the customers to our exchange facilities over fewer fibre pairs. So in that ?? with that need, the point to point model is sort of obvious.

But, even so, it will still be a lot of fibre stuff and lots of ?? well, a lot of WDM things to connect and measure and deal with with with you will a the time. So, I am not saying this is trivial. I am not saying we didn't make mistakes, because we did, and we learnt from them, but after this initial learning exercise, I think it's kind of weird that this is working just nicely and we have moved a huge number of our customer base, which were located in these various co?low facilities like Telecity and Indishin, over to the WDM infrastructure.

The Trans?mode stuff is, and here I have to really expose my ignorance, because yes, I played with Transmode stuff myself but I have never even touched anything else than Transmode in practice, but what the other people at NetNod tell me is that Transmode stuff is sort of bare?bones. It's viable for us from a pricing perspective, but it's somewhat less fancy than what you may get from other suppliers, which was just fine with us. But, in spite of being less fancy, there is the traditional CLI interface which is what we use most and there is also all sorts of GUI based interface with this.

There I leave is open to questions.

CHAIR: Any questions? Nick.

AUDIENCE SPEAKER: Nick Hilliard: Did you have any legacy coloured trance receivers that you had move over to your Transmode boxes?

SPEAKER: No, we didn't.

AUDIENCE SPEAKER: The reason I ask that question is from the point of view of using a third party optics in equipment, third party optics tend to be the same optics, the same model numbers, but maybe a third of the price, now not in Transmode case, Transmode actually do' competitive pricing for transceivers, but for some manufacturers they hike on a huge amount of overheads on to transceiver pricing.

SPEAKER: I will say when you speak about having left over coded optics from from previously, if we look at this from an exchange point of view, everyone running an exchange point knows that we have the same business problem as everyone else, as in should we buy new stuff now or later? And later is always cheaper etc.. but also, in the exchange point case, very important factor is that later means denser. So, you want to have more ports out of a particular card etc.. and this is not my station problem we have to deal with when we look at the switch factors. When we only have the switch fabrics, that's just one optimisation problem. Now we have two. Because we have the same situation with the WDM systems when it comes to the number of colours that we want to get into and out of this point to point thing. And we have the same problem when it comes to when to do, make new upgrades and investments and getting the maximum useful lifetime out of investments when it also comes to the WDM system. So it's kind of clear that in spite of this being the right thing to do from a systems cost perspective, it really made our business optimisation problem harder.

AUDIENCE SPEAKER: In the now later argument, what are your thoughts on 100 gig connections?

SPEAKER: I have no thoughts there. Well, obviously it will happen. My guess is that NetNod will not be the first adopter. We will not be the last adopter. But, we are ?? well others are clearly following what's happening there, but personally I am not the person to ask.

AUDIENCE SPEAKER: Martin: Martin Leavy: Can you talk a little bit about the reliability of going to the D W D N method for the distant methods versus the customers putting whatever extended reach opt particulars to take the extra fibre length out from outside the city?

SPEAKER: Not really. I mean.... I guess you and I can sort of play with that more or less from the same level of expertise, because it's not what I do. But it's kind of obvious that if you have multiple customers between two sites and they are running on different fibre pairs, they have the situation while one fibre pair may have a problem while the other one doesn't. On the other hand they are typically in the same trunk and all the fibre pairs in that trunk may have a problem at the same time. So it's not the case where we are necessarily ending up in a situation where we hurt many customers or the fibre company hurts many customers because of a fibre cut where we otherwise would not have a problem for most of them because they would still have been in the same trunk. But in the end it's sort of clear that yes, having more customers in the same fibre pair is an increased risk from some point. On the other hand, fibre companies, they are providing all sorts of new services, like redundancy of various clients and cut over times that are decreasing over time etc. And in that kind of situation, if you have ?? if you have a service from the fibre company that says we will with move this over to another trunk within this amount of time, it could actually be ?? I mean we are just talking theory here ?? it could actually be that that's quicker than to have lots of fibres you need to move over in the same window. So, in the end, I don't have any numbers, but I guess we are more or less no worse off than previously.

CHAIR: Thank you very much.
(Applause)

Okay, I think it's me presenting the next one. This is on trill, which is a switching feature that's going to I think be really really popular within this community with the Internet Exchange in this community. So...

Let me explain the problem that it solves. On this screen is a typical layer 2 segment that many exchange points might look like or might have looked like at some point in their life. It's a ring of switches, because it's a ring in order to prevent the effect of an Ethernet loop, one of the links is blocked. And as the exchange grows and scales you add more and more links, but ultimately, unless your network continues to look like a perfect ring more than one or many linking will continue to be blocked. Which means that you go and spend some money on linkings that you want to use and you go and spend money on links that you really hope you never use.

It also means that traffic follows some inelegant paths. Although there could be an end switch link that you are paying for, traffic will not flow on that link if the link is blocked by spam tree or whatever you use, which means that you are getting a really poor return on investment from this infrastructure that you must buy. Additionally, there are quite a lot of ways to configure loop protection in your network and it's not the hardest thing in the world to set them all wanting to speak a completely different link protection protocol at all. Even if spanning tree there were very he forms of spanning tree, so actually configuring what you intend ?? obviously it's very, very possible, but it's an additional challenge. Additionally, you can actually use ?? you can have a different tree for different 1 Q sub nets on your network, which means that traffic then does start to use some of the links that are only block in one VLAN but tuck make debugging more interesting. Also some loop protection protocols don't understand the concept of capacity or cost so you can end up maybe blocking a capacious link and also convergence time might mean that with some ring protection implementations you lose a link like in the top corner here and it can be up to 30 seconds before that switch is no longer isolated again, the other link becomes unblocking.

So the premise of trill, as summed up by a rich list RFC, or informational RFC 556 is there is a number of features in modern layer 3 routing protocols which is would be beneficial.

And I prefer the way that they put it in the draft proposal. Which is "With packet HOP counts we now see the network need not be loop free."

So this is how it works. A link state protocol runs between all of the switches we are referred to as routing bridges in this protocol proposal.
All other switches in a layer 2 segment know all of the other ones.
And optimal paths are converged for known destinations, single Unicast MAC address destinations, so if a packet reaches a switch or routing bridge that go with with a known destination, there is a configured and converged path that it will take.
The proposal also recommends, well mandates that the construction of one or more trees for delivering unknown frames, or frames with unknown MAC addresses and broadcasts and multicast destinations.

The link state protocol is essentially I SAS with a small number of extensions, the way is works, each link sits on your network between switches, hosts an election for a designated R bridge, that designated R bridge appoints forwarding roles what's job it is to watch traffic go past, sense and discover end node MAC an addresses and distributes sort of a directory of which end node is on which switch. So, that the Unicast known destination configuration can be is possible.

The way it it works is that trill packets on inter switch linking an encapsulated, or the original packet is encapsulated with a trill header. Frames on inter?switch links get this extra header wrapped, which contains a hot count so that you can mitigate accidental loops or transit loops and they also know the exit name of the bridge so that they can forward HOP by HOP to the ultimate destination.

Here it is, here is the example pictorialey. This is a known Unicast forwarding the behaviour is defined by simply having a destination MAC that you know. The first R bridge, the one at either the top or the bottom, depending on the flow of this traffic, encapsulate the frame of the trill header before it goes on the exit port. And that header also knows that the destination switch ?? knows that switch by name and forwards HOP by HOP to the destination switch and then ultimately the last switch, unencapsulates the packet and sends it to the end node. The whole process is fully transparent to end nodes.

Puttey destination packets are delivered over a tree, but interestingly, several trees can be built by a trill network or a network that supports trill. It's not a spanning tree calculation. It's a shortest path first calculation. Links on the tree which are discovered to have no down streams nodes which are actually pruned to make the convergence more robust and faster.

And essentially, each switch knows in terms of each tree, what is an up switch and what is a downstream switch, so that although it can be ifsly patched in a love the network displays loopless behaviour.

The benefits of trill to IXPs, shorter layer 2 paths with meshing, therefore improves ?? reduces latency on your layer 2 network and you get money from the links that are currently sitting there and you are hoping they are not used. A beautiful connectionless protocol and configurationless protocol is much nicer than the ?? oh I have changed it to broken loop prevention protocol faults which we see on switches today. And the unexpected traffic is easy to forward, unexpected increases in traffic is easy to forward because you can actually configure multi?path forwarding destinations on your network. If two switches a one HOP away you can send the traffic over different paths on the same layer 2 network, which is really, really cool.
Any questions?

I see Aaron with a question.

AUDIENCE SPEAKER: Are there any existing vendor implications of trill today?

SPEAKER: There is certainly none that you can go out and buy, that I am aware of. Maybe someone in the room can correct me. The proposal is in the RFC editor's queue, which from my limited understanding of the IETF means that everyone stopped fighting and we have converged on a protocol that we all like and that will freeze and then vendors are more likely to implement it because it will be a standard. That's what I understand. I am hoping for these features in the next say two years, maybe I'm hopelessly optimistic, there is giggles in the room. But I'd hope to see it in two years in all the big boy vendor networks.

AUDIENCE SPEAKER: It would also be interesting if you present on this in the future to get some feedback from vendors on the intent for migration from RS T P and if you can have them running at the same time for large fabrics.

SPEAKER: Yes, the migration or networks or whatever to a loop filled trill network is really going to be interesting. I am sure we are going to enjoy that maintenance, yeah, but as soon as I have some operational experience, I am going to really look forward to what that is.

AUDIENCE SPEAKER: Nick Hilliard. Somebody described the difference between loop management protocols and routing protocols like trill as being the difference between where you are specifying where your traffic can't go for things like STP and so forth and specifying where your traffic can go for layer 3 protocols.

As a general comment on trill, it looks really good and I'd love if all the equipment that I had would support it in the future. But most of it probably won't and that is because a lot of the equipment doesn't support generic layer 3 forwarding, and trill is really breaking down the barrier between layer 2 and layer 3 and I suspect what we are going to see in the future are mixed layer 2, layer 3 switches and they'll do, you know, sort of trill with layer 2, MPLS, IP, the whole lot. I hate using the word converged, but converged might be a good description of what we see in the future.

SPEAKER: Possibly. The switches that a lot of us in the room probably use do support layer 3 but not in the same way as a router does. I think one of the design ambitions for trill as well ?? sorry was that it was light weight enough to run on equipment that's typically deployed. I hope I'll be able to see it just by installing the latest software on my switch in a couple of years, but time will tell. Okay.

Are there any more questions?

I think Michael is next on the agenda to do ?? oh, there is a question from Jabber, sorry.

AUDIENCE SPEAKER: A question from James blessing, that is: What are the benefits of trill versus VP L S?

SPEAKER: That's interesting, that's a great question. The AMS?IX model, or I guess it can be called that because they are using it. Using VPLS is a really good model and trill implements a lot of those features I guess at layer 2, which AMS?IX have had to deployed with MPLS because these features aren't here today, so they have been able to build something that's equivalent using the features that are here today because they needed to solve a problem today. In the future trill is more likely to be useful to small he err exchanges. No one from AMS?IX wants to comment? I haven't put my foot in anything. Okay.

I guess the VP L S solution also lends itself well to the resale model that you have tried out which means that you have been able to roll out additional services on the back of what was maybe a scaling project. So, it's been useful for you in that way, but there are a smaller number of exchanges with equipment that can support a VP L v? in the core, so I think for example, we are watching this more than watching VP L S. I think...

Okay, are there any more questions?

All right the thank you. And I'll hand over to Michael.
(Applause)

SPEAKER: Michael: I am Michael working with telex. We are currently operating four I Xs in the US spread across the country a little bit in New York, Atlanta, Dallas and Phoenix.

Starting in 2009 we were getting approached by several of our participants on the exchange to get a working toolset help them manage their connection to the exchange, their peering relationships and other facets. We kept getting random requests, none of them seemed really to agree on what they wanted most so we started surveying everyone. We got about an 80% response on a survey saying here is a list of features we think we could implement and give us a list of features you think you want. In the end, we ended up and going through and coming up with an easy list that we could implement that was not too costly. We have another list of features that people have said we really love to see. Some of them are impractical, impossible or incredibly expensive. But we tried to do our best to implement everything that we can.

The number one thing people wanted to do was have complete control over their interface. Unfortunately some of our connect members either don't see use statistics on their interface or they actually have to request from their IT group a graph of their interface, so they came could us asks ask you give us some MRTG graph. So, certainly, that's easy, we have the data, here it is. You might have multiple ports. You might have lag ?? we actually have one participants that has a lag group but for whatever reason their MRTG system will not grab is SMTP ?? they wanted to see what the actual port channel to see what that was accurate.

You know, simple viewing was not enough obviously. We'll get to that in a little bit more details. SMTP. We probably answer five or six e?mails every time some participant has any kind of an outage. They come to us first and say what happened last night. Did somebody blow up? Did the person misconfigure their BGP? What's going on. So the portal, we keep a little running history. We tell people about future events that might be coming and this is actually since we have implemented it, cut down on the e?mails that we received from participants saying hey, what happened last night. They can go on and see it, read it for themselves.

With that, we actually had a problem come up a week ago with participants that they exceeded their max. Prefixes to the majority of their peers and went down for a considerable amount of time. Their knock didn't notify anybody that they were down. They heard about the outage from us. Our alert system went off. We saw their session down and we contacted them and their engineers started to connect the problem worldwide. At that point they came back and said hey you got an alert about that, can you forward that to me any time you get T great. So we incorporated into the portal the ability that a customer can go in on any interface, any BGP session, they can actually set up an alert system in our system and we'll send them a notification. Whether it's through e?mail, SMS or other contact methods. They can simply just select a check box and say yes, notify me whenever you see a problem.

We also have the ability that the person can drill down specifically into the interface, we run static MAC an addresses on every single port and at 2 in the morning when someone wants to do a maintenance, they have to ?? in the past contact us, coordinate with us to do a MAC address change. The other day we had a participant that replace add router in an area in New York and they had four different eye axes all connected to that router, everyone of them had to be contacted to do MAC address changes, ours was the only one that came within the four hour maintenance, the other kept having to ping and pole to get them to do it. We have the ability that they can actually go into their interface, they can shut it down, bounce the Court if they exceed max. Address prefix limit or they can delete their static MAC address so they can do a port replacement. At that point in time we see the new MAC address come in, register it as a static and they are done.

You can see standard MRTG graphs for length of type. We actually maintain five minute samples for two years. So they can actually go and see actual samples where a lot of companies main tape five minute samples only for a few weeks.

We have a peering manager to help coordinate peering at any participant can go in and see any exchange point they have in common with other participants. They can mark that participant as somebody they currently have an active BGP session with, they can mark that person as someone they deem unqualified to peer with. And what that does is when that other participant logs into the same portal, this he don't see them in the list of potential peers. They can also contact the company. We actually pole or mirror the peering DB so we have all the contact information immediately available for that so they don't have to go and look it up and try and figure out who they should contact. We maintain it here and give them the ability to drill down further and control which of their peering DB records they want to expose.

In the decision process if you want to contact appear, you can drill down and you can click on them and see how many routes they have, their IP addresses, so you can either help establish your configuration new router, or know whether or not you want to peer with them, are they a good v6 peer or not.

You can also look and see what your current statistics across our platform are, one quick shot to see are you sending consistent routes. Since implementing this we have two participants on the multiple exchanges figured out they were a participation problem and were not announcing consistent routes across their network.

You can go in, you can see their peering policy that they have published, we are peering DB, we to require that all of our participants set up BGP with our route monitor box, this is not a route server or anything, this is a box we monitor to make sure their port is up and BGP session is up. You can go in and see specific information about how many routes are advertising, amount of picks, v4, you can go down the list and make sure you are peering with everyone that has an open policy.

You can go and see any current known outages that are currently happening, whether somebody's port down or BGP session is down, you can see any pending requests of people that are ?? or have signed up to join the exchange but haven't turned their port up yet.

General statistics about our switch as a whole. You can see the number of v4, v6 routes being announced in a specific city or aggregate between all of ours. Traffic for our exchange over time. We have a full blown looking glass, the standard stuff, you know.

You can manage your contacts that you have in peering DB, so that if you have multiple listings in peering DB but you only want people to use one or two of them or none of them, you can actually hide those from the rest of the world inside of our portal.

We have, in the past, run several list serves for emergency notifications or hey please peer with me. The problem was every time you need that had list serve you couldn't remember address you subscribed to or what the address was, so it ended up in you e?mailing us asking what the address was. Which really stung at 2 in the morning when someone said I needed an imagine contact everyone because I tripped MACs filter limit and I don't have a great way to reach out and touch everyone. So we have built into our system a bulk e?mail err, if you will, that you can drill through their listing contacts in peering DB, select who you want to. What we do is if we is see a peering at or anything with peering in the name in peering DB, we select that by default and leave the others unchecked. If you don't have that listed then we'll check everything you put in the peering ?? as everyone you can get a blast.

You can drill us down to send the contacts to anyone in all the exchanges or any exchanges. Say you are on our Atlanta exchange and you want to join New York, send and e?mail to everyone in New York, I am interested in changing who there would peer with me?

We have a list of things they're going to be implementing soon, this is based purely off of our participants coming back with requests. Remaining in requests, system one is people want to see things like the per AS flow stats, so that's coming real soon. And the Renesey's market intelligence reporting, we are going to fold all that in. We have a list of other features determining whether or not we want to implement.

Like VIX, as we start exploring route servers and getting those online, you'll be able to do full route server management as well, but until we have that we are not listing that as a new feature really.

So, any questions?

CHAIR: Thank you Michael. Are there any questions?

I think that's a really good tool, so thank you for demoing.
(Applause)



CHAIR: Okay. We are a little bit over, but there was some interest this morning in people seeing the version 2 of the euro IXP film competition, if anybody urgently needs to put their glad ration on for tonight, you are able to unrun off and do that now, but if you want to see the version 2 of the euro IXP film competition result, then John will be able to demo that for us. Do you want to say a few words?

John: New and improved, updated. Everybody can remember, anybody seen Warrior of the Net? Anybody remember this, a very dark, mysterious man mated packet throwing through the network. Technically accurate, a wit long, very dark, but I tell you what that movie had no heart. It really ?? wrong reference. Anyway, the other problem with it of course is there was no Internet Exchange in this movie. So, I mean what's the euro IXP but an association of Internet Exchanges there to promote Internet Exchange points. So we thought we needed to get a new set of information together to get the message across. We had to tell our story to the public ?? sorry, that's the wrong picture ?? what we wanted to do ?? we wanted to tell a non technical educational entertaining and wholesome story so the public about Internet Exchange points. So we decided to form a Working Group, and the Working Group didn't really want to do too much work so we thought we'd hold the contest and let the contest participants figure out how to tell a story. We wrote a brief, provided that information to contest participants, found sponsors, screened their submissions and selected a winner. Then we ran it at the last RIPE meeting in Lisbon, and got a fantastically, well detailed response about how we messed up a number of items in the film.

So we politely took those things under consideration, and went back for a redo. And what I'd like to do now is just click the button and let you have a look at our second ?? the Internet revealed redo.

(Film played)

So, thanks for watching that again, those anoracks of you in the crowd who maybe even noticed any of the edits, they are somewhat subtle but we think tell the story in a more technically accurate way, and as clearly as we can for a broad, broad audience.

So, with think the communication challenge has been solved. It's a novice audience. It's technically accurate. We are showing the value of an Internet Exchange without necessarily making us a target for regulators. And we have made it as right as we can. I think the one thing we'd like to ask you to do is if you find this at all interesting, perhaps it's something that you can publish on your web sites or had he been people understand what exchange points do and use it as a vital marketing tool to just explain how you are working to increase communications globally. Everyone can become peering Zen Masters.

Thanks to the Working Group, the list is here. And then all of our sponsors who you see on the page.

Any questions or comments, we'd love to hear them. Thanks a lot.

CHAIR: Michael?

AUDIENCE SPEAKER: Michael: Is there a higher quality version available than the one on YouTube?

SPEAKER: Yes, this is an 800 mega byte file that you can download from the website.

CHAIR: Are there any more questions for John? Well thank you very much for sharing that again.

AUDIENCE SPEAKER: Congratulations, it is very good, the video. It is available for usage or ??

SPEAKER: We put it together as a service, we just want all the credits at the end to remain in tact that says who did it and why, otherwise sure, it's available and we can help you get the links. Serge can help you at Euro IX as well.

CHAIR: Thank you everyone. Sorry for running over. I hope you found it useful and entertaining. So we'll see you in Rome if there is nothing further to add.

(Applause)

LIVE CAPTIONING BY MARY McKEON RPR

DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.

WWW.DCR.IE