Rob Blokzijl: Good morning. It's 11 and I suggest we start now. The last session of this RIPE meeting, and as I announced yesterday, the first half hour will be taken by a combination of Address Policy and Working Group, and IPv6.
So please.
SPEAKER: We'll start by trying to explain what the issue is.
So here is the problem statement, policy 2009‑05. Sorry my voice is not quite okay. Do we accept that a /32 is the most specific prefix that should be routed in the global IPv6 table and accepting that this has consequence of causing wastage of address space. Or do we continue with the needs‑based allocation of address space and allow LIRs to split their /32? Both options mean extra prefixes in the routing table and this is an example to illustrate what the problem is.
Sander will ‑‑ Policy Working Group Chair will explain the next one.
SPEAKER: In the current situation we have some things in an address post document which actually are about routing, which is that the document specifically says that the minimum allocation size is there to facilitate filtering, which might not be the correct place to put it, and it also says how somebody should advertise the address space they receive, at least for v6, so what ‑‑ as Working Group Chair, what we're wondering is do these things really belong in an Address Policy document or should we document this in a separate document maintained by the Working Group? So the question we have at the moment is: Should we actually move these things away from Address Policy towards routing and formulate a document with recommendations on how to filter, how to announce prefixes, and don't bother with that in policy documents because we can't check it anyway. They are there but we can't enforce it. So that's our idea.
SPEAKER: So there ‑‑ how do we balance routeability versus address conservation. Is IPv6 space plentiful enough that we should allow /32s to be allocated on the basis of routeability or should we come up with guide lines or combinations of what filtering should look like for IPv6? So these are the issues, how these came about to be. Now, the floor is open for you to...
RUEDIGER VOLK: In particular, we should avoid putting stupid recommendations and arguments into policies and arguing ‑‑ well, okay, telling people that prefix length base filtering is the essential way to filter IPv6 in the future. It's completely brain damaged.
(Applause.)
AUDIENCE SPEAKER: Just to reinforce the thing, we need to get to a stage where filtering is very specific and content based and actually taking into account and producing routing security. And that's completely out of range for Address Policy anyway.
SPEAKER: Thank you.
AUDIENCE SPEAKER: Marco [] X S 4 all. I hear Ruediger, and I understand Ruediger, but I also think that what he wants is the way we should go but it's going to be a long road before we get there. In the meantime, we do have an actual problem as I regard it, IPv6 has been a theoretical problem for the past 17 years and we're finally deploying stuff and we ran into some small issues there, and people have actual problem and we need to solve this problem, and whether we solve it by allowing them extra /32s, allocation, PI, whatever, those routes will be there, and we need to fix that. If I put on my engineering hat, the only thing I basically want is to have it properly documented, at least if we tell people what we're doing here in the RIPE region, what to expect, people can build filters accordingly the way they want it, and if you want it prefix build, feel free, if you want to go certificate base, go. The main point here is we should document, be clear about what we expect, be clear on how you should filter. And it's sent on. We know that if we stick to those recommendations policywise the likelihood of your prefix being carried in the global routing table will increase. We'll never guarantee routing. We didn't do and and we won't do that. But increasing the likelihood of your prefix, reaching out there only gets better the moment we document it. And from this whole perspective point, yeah, I think Routing Working Group is the best place to solve it. But bear in mind that if you simply drop it from ‑‑ from the policy stuff, as ‑‑ this should be ‑‑ sorry, it's been a rough night. Make sure these things stay in parallel. There shouldn't be a gap there. Make sure that routing recommendation or whatever it's going to be, best practice is there at the moment, you drop the stuff from the 466 document.
SPEAKER: Thank you.
AUDIENCE SPEAKER: Remco. Also had a rough night.
As for your suggestions, suggestion one, yes, as quickly as possible. I don't think these kind of guide lines are in the right place in the RIPE documents. As for the second, I suggest that we spend the next 20 years talking about that.
AUDIENCE SPEAKER: Philip Smith, Cisco. To the second point, we already have RIPE 399. Is that not good enough? I agree with the first point to remove them, they don't belong there. The actual wording was something like must be there. Even if we want to say something it should be should. We don't have any business telling I Space what to do. RIPE 390, separate route. That discusses routing. Again it's a recommendation document. People can read it if they want to, if they want to ignore it, they can. We should stick with that.
SPEAKER: Anyone else? I see.
AUDIENCE SPEAKER: Not speaking as Address Policy Working Group Chair here because I'm sort of guilty of distributing filter recommendations that have prefix length in them. This was done to fill a gap because there were no recommendations at all. People were not filtering at all. And stuff was leaking. I'm not insisting on maintaining this myself, and the reason is always ‑‑ don't take this as the wisdom of the sage, but think about it and apply it to your network. And I would be actually happy to have it for the ‑‑ in a Routing Working Group document, and of course I'm willing to help with it.
AUDIENCE SPEAKER: Marco again.
AUDIENCE SPEAKER: I want to say that there's also a document made by RIPE with the minimum allocation size made from IPv4 allocation and IPv6 allocation and as far as I remember there's another set of /32 and people tend to believe that this is the minimum allocation in those bigger RIPE allocations, and they could filter on that. If we start dividing our allocations from 32 to 33s or whatever, smaller, that could be a problem, because there is a single document saying that that's the minimum, and people tend to believe that. People believe RIPE NCC because they deserve this.
SPEAKER: The document actually says it's the minimum allocation size which doesn't say anything about how many parts you can route it on the internet.
AUDIENCE SPEAKER: But you can imagine how many people don't read anything else. Minimum, that's ‑‑
SPEAKER: The current document actually says it's to be used for filtering. So we at least want to get rid of that.
AUDIENCE SPEAKER: I agree. Just remove that. But still if we do not state clearly, at least in that document, with the minimum allocation, that this could be not minimum road, maybe that will help, because people ‑‑ from my own personal experience, they read the document, read the word minimum, they even ‑‑ because of the language problems, they even sometimes maybe not understand the word allocation, specially people from smaller ISPs, so on, they do not understand the difference and they tend to believe this is the minimum and the filters will be okay. So maybe we should put in that document should word for this is not the minimum road or not intended to be the minimum road or whatever, because as I said, they believe that.
SPEAKER: Thank you for your suggestion.
AUDIENCE SPEAKER: Marco again. I think I said it before but keep in mind what you're actually talking about, how many routes are we talking about being deployed. And yeah, the route table will grow because people will start using it and if it hits the 20,000 mark anywhere in the near future, bears on ‑‑ it means people are actually using IPv6 and that's not an invitation to leak.
SPEAKER: Whatever the starting points, if it's two separate networks you'll have two separate routes either from one /32 or somewhere else.
AUDIENCE SPEAKER: In effect the length of that doesn't really matter for how much it consumes, it just eats the slot and it's 32 or 35 and that's the whole point there. . The problem that it will be fixed and there will be an extra route whether PI or PA, 32 or 35. The route will be there and it will eat memory. Forget about discussions about length.
AUDIENCE SPEAKER: Google. So I appreciate this proposal to remove route filtering. And as I mentioned previously, specially for content providers there's a real need to advertise more than one prefix and therefore it should be somewhere addressed in the policy documents, whether it's going to be more specific routes it doesn't matter but it's very important ‑‑ it means for traffic engineering you can't effectively deliver similar service as you're delivering now for IPv4.
SPEAKER: Thank you. I don't see anybody at the microphones at the moment. I have a feeling that there's actually quite some agreement in this room that we should go forward with this. So we will work on a proposal for the documents and send them to the appropriate mailing lists.
Thank you.
(Applause)
Rob Blokzijl: Right. Thank you. This, I think, was the last of real working sessions, and I would like to take this opportunity of thanking Joao for lots of jobs in the last few weeks before this program was put together, and we decided to show our appreciation in an appropriate manner. Thank you.
(Applause.)
There are a few short items left here. Announcement, progress report from the data protection task force. We have this task force and I have the feeling task force is desperately trying to come to a conclusion in order to disband the task force, but the task force should produce a deliverable...
SPEAKER: I'll keep it quite short. As Rob said, I think we have the ‑‑ had the feeling that we wanted to disband it ‑‑ actually the previous RIPE meeting already. But there's still quite some open action items. We'll continue the task force for now. The reports were delivered this morning in the Database Working Group, not that I didn't want to say anything here but all of the action items are very databased related so we felt it was present to present that there. But I'm open to any questions or comments if anyone has any.
Okay. Thank you.
Rob Blokzijl: Thank you. At the last RIPE meeting, the Working Group Chairs who usually meet once during the RIPE meeting to discuss administrative support items, brought up the suggestion that not all of our policy documents are written in a language that makes them easy to read. Various reasons. One of them is there's a lot of input from different people, it is usually not the result of proper editorial writing of a piece of text, which creates, sometimes, confusion which creates, sometimes, the impression that there are internal inconsists. So we thought it to be worthwhile to do an experiment and take one of our documents and the one we chose was the policy development document and ask one of the RIPE NCC technical writers to go through the text and turn it into a more ‑‑ into a better wording, better phrasing, and increase the readability. This has been done and we had a look at this, we being the Working Group Chairs feeling that this document, Working Group policy process is one of the most important working tools. We think we have concluded this exercise and the rewritten document will be published by the end of next week for you all to have a look at it. If people agree that this is a useful and worthwhile exercise, we will, in a very careful manner, take the various existing documents, whereby, of course, we'll take the ones being used the most first, and slowly but gradually coming to a higher quality, better readable, and, therefore, more useful set of documents. Of course, rule number one is this is improving the text, it's not sneaking in new policies. So it will be under the scrutiny of at least the Working Group Chairs, but the community at large, of course, is absolutely invited to check as well.
So this was a progress report. By the end of next week, you can see the first results and read it and enjoy.
This brings us almost to the end of the meeting. We have a few traditional issues left. The RIPE NCC has been running a service desk this week and it's good tradition that among the people who make use of this small lottery is held and there is a little prize.
SPEAKER: I'm going to pull a number, everybody who has received a number while visiting our Services Centre, so pay attention. The number is: 18.
Rob Blokzijl: With all these RIPE‑organized sweepstakes, there is one rule, if you're not in the rule, you lose your prize.
SPEAKER: We'll go for the next.
12.
Rob Blokzijl: 12. (Applause.) Thank you. And while we're at it, this RIPE meeting has been the largest ever. We had 422 attendees present at the meeting, excluding RIPE NCC staff, so all together we were about close to 500 people this week, which was a pleasant surprise to all of us that the community is alive and vibrant.
Running such a meeting takes a lot of effort and input and hard work from the NCC staff. I thank them all for that.
(Applause.)
RIPE meeting, as far as participants are concerned, starts with your registration well in advance of the meeting, and, the earlier you register, the better the planning process goes. So those of you who have been here before have an idea what is coming now, and that is the first three people who registered for this meeting, we would like to thank them with a little token of our appreciation.
So on your badge, in the corner where it says RIPE 58 and then a number, your registration number. I'm number one, but that is a registration software feature, but number 2 is Dave Wilson.
Dave, are you here?
(Applause.)
Number 3 is Job Witteman.
(Applause.)
He's the managing director of the Amsterdam Internet Exchange but we know him better as provider of great parties.
(Applause.)
And number 3 is [] Andrevy surray.
(Applause.)
Thank you again for your early registration.
Mentioning parties, we had not only a very ‑‑ a very productive, sometimes overcrowded meeting program, we also had entertainment in the evenings, and as usual that is provided for in the first place mainly by sponsors, and the sponsors of the social events this week, I mentioned already the Amsterdam Internet Exchange but also a...
I think we should give them a big round of applause. I think that part of the program was also implemented in a very face fashion. I do know that some Working Group Chairs that the early morning slots throughout the week are not the most faithful anymore.
Right. As usual, all presentations and archives with a web cast will be available sometime next week on the RIPE website.
Now, it has come to my attention that one report is still coming and that is the secret Working Group. From the look on some of your faces this is the real wake‑up call.
SPEAKER: That's the wrong sort of thing I want to show.
So when you saw me walking up ‑‑ this works like that, I guess.
SPEAKER: It's upside down.
SPEAKER: Yeah, thank you. So I walk a little difficult, that is not because they tortured me to come up here but they're still sending my boots from the last RIPE meeting.
Secret Working Group report, more than 20 years of violence. These evil bastards have been around for a long time and keep pushing us into this thing.
Straight to business. Inspiration is always found by Google. So we typed it in and you can do this for yourself and what you can see will go without further explanation.
Without further words. I think that the top right one is the position that RIPE is in currently.
What do you say to a young adult when you're a parent? Still at some occasions you say grow up and that's the subject of the first Limerick. 20 years of RIPE meetings this year full of arguments, issues and beer, but it's been so much fun, we're not yet 20 one. Are we assault yet? Never. Hear hear
(Applause.) What is on the mind of a 20 years old, that's always the question. And ‑‑ but that aside, you might have seen of notice that the last few years Krasnapolsky Hotel has increased it's delicious snacks that appear in between meetings. Epicurean miracles I call them from pastry and chocolate and so on and so forth.
The secret Working Group found a strange object though, it was a weird kind of lollipop sort of cookie and that inspired one of the 20 years old virgins to ask a question: At the breaks lovely things on a stick nice and hard on the sides quite a hit but all creamy inside and it's hard to decide if it's better to swallow or spit.
(Applause.)
This is one of the worst ones yet, I must say.
SPEAKER: You were saying something about violence?
SPEAKER: Don't go there.
We all know this picture. It is depicting a future that brings large uncertainty and doubts. The secret Working Group has been aware showing this picture more often. But there is a problem. It is a data set that's been known by the community for years, but the problem we're hearing is that people have fitted models to this data set and these models have resulted in panic, ulcers and work towards global deployment of IPv6 which may be is not necessary, because you all know that statistics and models are basically lies and the secret Working Group is relatively convinced that the community has been tricked into an action that was not needed. I must say that this has been all been caused by Cobal that claims to have con sense suss and review and the secret Working Group believes that it is not true, this is a vital mistake and needs to be corrected. So the secret Working Group as a science department, I would like to introduce the science department to you.
(Applause.) And if turns out all the mathematical models that have been used previously are the wrong ones. Obviously when one seeks mathematical models one seeks complicated models and one of the most straight forward functions in mathematics was the useful one, it's the second word, polynomial. There is no need for IPv6 you can all go home. Thank you.
Can somebody call Geoff Huston? For for for for for those not used to old Latin script, this is English, please.
The massed ranks of the spamers look out, there's a posse of cowboys about, it's a father and son, please be wear when they're done, if you're Chinese or Dutch or a kraut. (Chinese, Dutch or)
I know of a father and none, preaching v6 at the point of a gun, once they had faith, but now they just hate, that with NAT they will always need STUN
(Applause.)
So most of you that have been around that is, I think, 4/5th of you giving the ratio of newcomers this time, know there are also the cultural snobs within the secret group that produce sonnets instead of Limericks. There we go. In May to sunny Netherlands we came, close by the red light district by the damn, to chatter not of earthly things or fame but ROAs routing loops and also spam all heavenly things and leading on and on to higher plains where air gets ever thin and arguments rage to and pro... but overall a smiling entity lays guiding hand and gently steers us past the rocks and shoals of network policy to land at end in harbour safe at last while Rob benevolent and even wise looks down upon us all and gently sighs.
(Applause.) (Many of you may wonder who these very cultural and eloquent works were inspired upon, or inspired by, I should say, that's shown in the next picture where the innocents have been protected. You might have seen this picture just in passing by and I know most people do not take a close look when they see pictures like this, but I want to give you the opportunity to take a close look.
(Applause.) ( I ‑‑ oh, this is really handy, you can walk over the stage and I can talk like this, but I had an experience while I was working down to the thing yesterday, normally when you walk there, there were ‑‑ people step up to you and say, you want to buy coke, I have nice pills. Yesterday there was this guy coming up saying, you want to buy TAR? , you want to buy tar? Are you looking for keys from affair, are you rootless not sure where you are, give your pusher a shout, but you better watch out, for he'll sell you a pit full of tar.
Our final piece of art, is inspired by something ‑‑ basically collaboration, we are getting much more involved as the secret Working Group in internet governance which we believe in the spirit of ‑‑ is a very good thing, even the most secret Cobals should step out and show their work. The following is a product of that:
There's a toy you can buy in the store, with the letters ICANN on the door, when you pull the string down, it sumps up like a clown, and says pick me, I'll give you some more.
So this is the toy, you see it's a little ICANN doll. How does this relate to internet governance? Very simple. For internet governance, you should pull there and the result is
Thank you. See you elsewhere, if not pressure will be applyed.
(Applause.)
Rob Blokzijl: Thank you for the nice summary of the week of hard work
SPEAKER: This is all you're going to get to take home.
Rob Blokzijl: If at least you take this home then you coming has not been in vain.
Right, I think we are at the end of this 58 RIPE meeting. I thank you all for coming. I thank the 149 people who came to the first RIPE meeting and I hope to see most of you back at all the following RIPE meetings. Following RIPE meeting takes place in October, October 5th to the 9th this year in beautiful Lisbon (LI S BON) Urgent message. Before you rush off to LI S BON, there's one report to come, you have all been using the network and you've all noticed there were a few hurdles this week, and as is the tradition somebody from the technical team will give a short report on the network service this week, at least that's what Nick told me.
My apologies.
SPEAKER: Hello everyone. Actually this was supposed to happen before the secret Working Group, but if you still need, like, a coffee would be in order then whoever wants to go for coffee, I think it would be all right.
Let's see, because this has been closed.
See, secret Working Group comes after. Actually that's not true. All right. So this would be the RIPE 58 technical summary. We're going to start by presenting the meeting team as usual, then a technical set up, the problems we've encountered and which you have noticed, some traffic statistics, wireless LAN activity and then some questions answered (LAN) we're actually in the standard team.
Ruben is part of the RIPE meeting technical team for the last eight meetings. He's leading the RIPE meeting tech team and I would very much like to thank him for the contribution he has made to the success of the last meetings.
(Applause.) (
Sheurd Alsterdyke is replacing Ruben and you might have already seen him during this RIPE meeting.
As for the technical set up, I chose this image that shows a logical presentation of our network. We're connected with the RIPE NCC offices, we're dot fiber, and the network is divided into three LANs and the routeers themselves use VRP and one is in the basement and one is in the up of the opposite room. I'd like to tell you about the problems by taking a few select among, thank you very much you know who you are, that came and reported every single bit of problem they could find. We highly appreciate that.
Mostly the problems that we have seen was even though we're coming to this hotel for quite a bit of time is because we've moved the operations room into somewhere else, at an upper floor, and mainly due to a longer e‑Net capable we started experienceing process problems with the network and the heavy load. They were intermittent on multiple fronts, they made diagnostic difficult but on IPv6 side they were a bit confusing, came from both routeers at the same time, could be related to the patch, again, one is up there and then the other one is in the basement. We did diagnostic and on Tuesday evening we took decision to disable VRRP all together and since then it was stable. The DNS resolvers at times were not reachable at the beginning and again DNS queries were traveling up the patch to the opposite room. So we bypassed that by using three DNS servers in RIPE NCC offices by bypassing that and then there have been some issues with the wireless access here in this room and probably this is the only ‑‑ the only problem, let's say, that has not been related to the patches and we solved this one by replacing all the wireless access points here with new models and reconfigureed them on Tuesday evening. By the way the stations are up 50 percent compared to the last RIPE meeting.
So all these three issues that happened almost simultaneously but intermittently on Monday and part of Tuesday, were solved by Tuesday evening. That was on the network side.
A bit on the system side. We didn't experience problems over there, but I will tell you that we have managed after several RIPE meetings to finally virtualize our server equipment and we started testing this technology about three or four RIPE meetings ago, and we never took the plunge, you know, just relying totally on it, and we keep on carrying the old physical servers with us all thes, just in case, just in case, and it worked very reliable for us. It actually allowed us to do some very neat things, such as allowing to have the RIPE meeting website up and running and updated at the same time while the server file cases are in transit flying or being set up somewhere else. And also, it has proven to be, specially away meetings, a fantastic disaster recovery solution.
Here they are, just travel with the US B sticks separately.
Let's talk about statistics, didn't have normal limits, didn't have much traffic, peak just north of 5 megabit per second. Very normal.
As for the wireless clients we had the peak of 300 users, which is a 50 percent increase from RIPE 57.
Questions?
AUDIENCE SPEAKER: What percent of traffic was IPv6 and IPv4? Could you tell?
SPEAKER: I don't have it ready. I would have to dig it up. Sorry.
AUDIENCE SPEAKER: I can comment on that. We didn't at this meeting separately set up those measurements because we didn't have the time so we don't have those numbers.
SPEAKER: Even more clear. Sorry.
AUDIENCE SPEAKER: Do your routers support getting these numbers?
AUDIENCE SPEAKER: Yes, the methods we used in Dubai was setting access lists, if I remember correctly, with counters, all traffic through and then look up the volume of the counters which only applied to IPv6 packets.
AUDIENCE SPEAKER: I thought there must be a better way but obviously not. One question: I wasn't here on ‑‑ I arrived at 9 ten or something on Tuesday morning and I know that James gave an update about the decivilians of the VRRP problem, can you repeat the D nodes of the issue again? We've seen similar things and the absence of it means you have to play around with ‑‑ I was wondering what exactly the failure mode was
SPEAKER: I think the best thing is to ask James to repeat his explanation to you.
AUDIENCE SPEAKER: We had the two routers doing the floating VRRP address and the individual addresses, so there were a total of three different routers servers coming out which depending on your client had strange effects. Juniper has a configure option to only do a router of the floater address and then v6 started worker
AUDIENCE SPEAKER: See it was sending RAs
AUDIENCE SPEAKER: Yes and depending on your stack decided doesn't know what to do, don't. You could guess an address
AUDIENCE SPEAKER: One of the routers goes down and my stack uses it.
AUDIENCE SPEAKER: Yes.
AUDIENCE SPEAKER: Excellent. Thanks.
SPEAKER: Any other questions? No. Thank you very much. (Applause)
Rob Blokzijl: Thank you and thank the team. Sorry, I now finish the sentence that was interrupted by this report. We are now really at the end of the meeting. I wish you all ‑‑ if you stay on in Amsterdam a blessed stay, otherwise for everybody else of you a safe journey home and see you at at Lisbon at the next RIPE meeting. Thank you.
So please.
SPEAKER: We'll start by trying to explain what the issue is.
So here is the problem statement, policy 2009‑05. Sorry my voice is not quite okay. Do we accept that a /32 is the most specific prefix that should be routed in the global IPv6 table and accepting that this has consequence of causing wastage of address space. Or do we continue with the needs‑based allocation of address space and allow LIRs to split their /32? Both options mean extra prefixes in the routing table and this is an example to illustrate what the problem is.
Sander will ‑‑ Policy Working Group Chair will explain the next one.
SPEAKER: In the current situation we have some things in an address post document which actually are about routing, which is that the document specifically says that the minimum allocation size is there to facilitate filtering, which might not be the correct place to put it, and it also says how somebody should advertise the address space they receive, at least for v6, so what ‑‑ as Working Group Chair, what we're wondering is do these things really belong in an Address Policy document or should we document this in a separate document maintained by the Working Group? So the question we have at the moment is: Should we actually move these things away from Address Policy towards routing and formulate a document with recommendations on how to filter, how to announce prefixes, and don't bother with that in policy documents because we can't check it anyway. They are there but we can't enforce it. So that's our idea.
SPEAKER: So there ‑‑ how do we balance routeability versus address conservation. Is IPv6 space plentiful enough that we should allow /32s to be allocated on the basis of routeability or should we come up with guide lines or combinations of what filtering should look like for IPv6? So these are the issues, how these came about to be. Now, the floor is open for you to...
RUEDIGER VOLK: In particular, we should avoid putting stupid recommendations and arguments into policies and arguing ‑‑ well, okay, telling people that prefix length base filtering is the essential way to filter IPv6 in the future. It's completely brain damaged.
(Applause.)
AUDIENCE SPEAKER: Just to reinforce the thing, we need to get to a stage where filtering is very specific and content based and actually taking into account and producing routing security. And that's completely out of range for Address Policy anyway.
SPEAKER: Thank you.
AUDIENCE SPEAKER: Marco [] X S 4 all. I hear Ruediger, and I understand Ruediger, but I also think that what he wants is the way we should go but it's going to be a long road before we get there. In the meantime, we do have an actual problem as I regard it, IPv6 has been a theoretical problem for the past 17 years and we're finally deploying stuff and we ran into some small issues there, and people have actual problem and we need to solve this problem, and whether we solve it by allowing them extra /32s, allocation, PI, whatever, those routes will be there, and we need to fix that. If I put on my engineering hat, the only thing I basically want is to have it properly documented, at least if we tell people what we're doing here in the RIPE region, what to expect, people can build filters accordingly the way they want it, and if you want it prefix build, feel free, if you want to go certificate base, go. The main point here is we should document, be clear about what we expect, be clear on how you should filter. And it's sent on. We know that if we stick to those recommendations policywise the likelihood of your prefix being carried in the global routing table will increase. We'll never guarantee routing. We didn't do and and we won't do that. But increasing the likelihood of your prefix, reaching out there only gets better the moment we document it. And from this whole perspective point, yeah, I think Routing Working Group is the best place to solve it. But bear in mind that if you simply drop it from ‑‑ from the policy stuff, as ‑‑ this should be ‑‑ sorry, it's been a rough night. Make sure these things stay in parallel. There shouldn't be a gap there. Make sure that routing recommendation or whatever it's going to be, best practice is there at the moment, you drop the stuff from the 466 document.
SPEAKER: Thank you.
AUDIENCE SPEAKER: Remco. Also had a rough night.
As for your suggestions, suggestion one, yes, as quickly as possible. I don't think these kind of guide lines are in the right place in the RIPE documents. As for the second, I suggest that we spend the next 20 years talking about that.
AUDIENCE SPEAKER: Philip Smith, Cisco. To the second point, we already have RIPE 399. Is that not good enough? I agree with the first point to remove them, they don't belong there. The actual wording was something like must be there. Even if we want to say something it should be should. We don't have any business telling I Space what to do. RIPE 390, separate route. That discusses routing. Again it's a recommendation document. People can read it if they want to, if they want to ignore it, they can. We should stick with that.
SPEAKER: Anyone else? I see.
AUDIENCE SPEAKER: Not speaking as Address Policy Working Group Chair here because I'm sort of guilty of distributing filter recommendations that have prefix length in them. This was done to fill a gap because there were no recommendations at all. People were not filtering at all. And stuff was leaking. I'm not insisting on maintaining this myself, and the reason is always ‑‑ don't take this as the wisdom of the sage, but think about it and apply it to your network. And I would be actually happy to have it for the ‑‑ in a Routing Working Group document, and of course I'm willing to help with it.
AUDIENCE SPEAKER: Marco again.
AUDIENCE SPEAKER: I want to say that there's also a document made by RIPE with the minimum allocation size made from IPv4 allocation and IPv6 allocation and as far as I remember there's another set of /32 and people tend to believe that this is the minimum allocation in those bigger RIPE allocations, and they could filter on that. If we start dividing our allocations from 32 to 33s or whatever, smaller, that could be a problem, because there is a single document saying that that's the minimum, and people tend to believe that. People believe RIPE NCC because they deserve this.
SPEAKER: The document actually says it's the minimum allocation size which doesn't say anything about how many parts you can route it on the internet.
AUDIENCE SPEAKER: But you can imagine how many people don't read anything else. Minimum, that's ‑‑
SPEAKER: The current document actually says it's to be used for filtering. So we at least want to get rid of that.
AUDIENCE SPEAKER: I agree. Just remove that. But still if we do not state clearly, at least in that document, with the minimum allocation, that this could be not minimum road, maybe that will help, because people ‑‑ from my own personal experience, they read the document, read the word minimum, they even ‑‑ because of the language problems, they even sometimes maybe not understand the word allocation, specially people from smaller ISPs, so on, they do not understand the difference and they tend to believe this is the minimum and the filters will be okay. So maybe we should put in that document should word for this is not the minimum road or not intended to be the minimum road or whatever, because as I said, they believe that.
SPEAKER: Thank you for your suggestion.
AUDIENCE SPEAKER: Marco again. I think I said it before but keep in mind what you're actually talking about, how many routes are we talking about being deployed. And yeah, the route table will grow because people will start using it and if it hits the 20,000 mark anywhere in the near future, bears on ‑‑ it means people are actually using IPv6 and that's not an invitation to leak.
SPEAKER: Whatever the starting points, if it's two separate networks you'll have two separate routes either from one /32 or somewhere else.
AUDIENCE SPEAKER: In effect the length of that doesn't really matter for how much it consumes, it just eats the slot and it's 32 or 35 and that's the whole point there. . The problem that it will be fixed and there will be an extra route whether PI or PA, 32 or 35. The route will be there and it will eat memory. Forget about discussions about length.
AUDIENCE SPEAKER: Google. So I appreciate this proposal to remove route filtering. And as I mentioned previously, specially for content providers there's a real need to advertise more than one prefix and therefore it should be somewhere addressed in the policy documents, whether it's going to be more specific routes it doesn't matter but it's very important ‑‑ it means for traffic engineering you can't effectively deliver similar service as you're delivering now for IPv4.
SPEAKER: Thank you. I don't see anybody at the microphones at the moment. I have a feeling that there's actually quite some agreement in this room that we should go forward with this. So we will work on a proposal for the documents and send them to the appropriate mailing lists.
Thank you.
(Applause)
Rob Blokzijl: Right. Thank you. This, I think, was the last of real working sessions, and I would like to take this opportunity of thanking Joao for lots of jobs in the last few weeks before this program was put together, and we decided to show our appreciation in an appropriate manner. Thank you.
(Applause.)
There are a few short items left here. Announcement, progress report from the data protection task force. We have this task force and I have the feeling task force is desperately trying to come to a conclusion in order to disband the task force, but the task force should produce a deliverable...
SPEAKER: I'll keep it quite short. As Rob said, I think we have the ‑‑ had the feeling that we wanted to disband it ‑‑ actually the previous RIPE meeting already. But there's still quite some open action items. We'll continue the task force for now. The reports were delivered this morning in the Database Working Group, not that I didn't want to say anything here but all of the action items are very databased related so we felt it was present to present that there. But I'm open to any questions or comments if anyone has any.
Okay. Thank you.
Rob Blokzijl: Thank you. At the last RIPE meeting, the Working Group Chairs who usually meet once during the RIPE meeting to discuss administrative support items, brought up the suggestion that not all of our policy documents are written in a language that makes them easy to read. Various reasons. One of them is there's a lot of input from different people, it is usually not the result of proper editorial writing of a piece of text, which creates, sometimes, confusion which creates, sometimes, the impression that there are internal inconsists. So we thought it to be worthwhile to do an experiment and take one of our documents and the one we chose was the policy development document and ask one of the RIPE NCC technical writers to go through the text and turn it into a more ‑‑ into a better wording, better phrasing, and increase the readability. This has been done and we had a look at this, we being the Working Group Chairs feeling that this document, Working Group policy process is one of the most important working tools. We think we have concluded this exercise and the rewritten document will be published by the end of next week for you all to have a look at it. If people agree that this is a useful and worthwhile exercise, we will, in a very careful manner, take the various existing documents, whereby, of course, we'll take the ones being used the most first, and slowly but gradually coming to a higher quality, better readable, and, therefore, more useful set of documents. Of course, rule number one is this is improving the text, it's not sneaking in new policies. So it will be under the scrutiny of at least the Working Group Chairs, but the community at large, of course, is absolutely invited to check as well.
So this was a progress report. By the end of next week, you can see the first results and read it and enjoy.
This brings us almost to the end of the meeting. We have a few traditional issues left. The RIPE NCC has been running a service desk this week and it's good tradition that among the people who make use of this small lottery is held and there is a little prize.
SPEAKER: I'm going to pull a number, everybody who has received a number while visiting our Services Centre, so pay attention. The number is: 18.
Rob Blokzijl: With all these RIPE‑organized sweepstakes, there is one rule, if you're not in the rule, you lose your prize.
SPEAKER: We'll go for the next.
12.
Rob Blokzijl: 12. (Applause.) Thank you. And while we're at it, this RIPE meeting has been the largest ever. We had 422 attendees present at the meeting, excluding RIPE NCC staff, so all together we were about close to 500 people this week, which was a pleasant surprise to all of us that the community is alive and vibrant.
Running such a meeting takes a lot of effort and input and hard work from the NCC staff. I thank them all for that.
(Applause.)
RIPE meeting, as far as participants are concerned, starts with your registration well in advance of the meeting, and, the earlier you register, the better the planning process goes. So those of you who have been here before have an idea what is coming now, and that is the first three people who registered for this meeting, we would like to thank them with a little token of our appreciation.
So on your badge, in the corner where it says RIPE 58 and then a number, your registration number. I'm number one, but that is a registration software feature, but number 2 is Dave Wilson.
Dave, are you here?
(Applause.)
Number 3 is Job Witteman.
(Applause.)
He's the managing director of the Amsterdam Internet Exchange but we know him better as provider of great parties.
(Applause.)
And number 3 is [] Andrevy surray.
(Applause.)
Thank you again for your early registration.
Mentioning parties, we had not only a very ‑‑ a very productive, sometimes overcrowded meeting program, we also had entertainment in the evenings, and as usual that is provided for in the first place mainly by sponsors, and the sponsors of the social events this week, I mentioned already the Amsterdam Internet Exchange but also a...
I think we should give them a big round of applause. I think that part of the program was also implemented in a very face fashion. I do know that some Working Group Chairs that the early morning slots throughout the week are not the most faithful anymore.
Right. As usual, all presentations and archives with a web cast will be available sometime next week on the RIPE website.
Now, it has come to my attention that one report is still coming and that is the secret Working Group. From the look on some of your faces this is the real wake‑up call.
SPEAKER: That's the wrong sort of thing I want to show.
So when you saw me walking up ‑‑ this works like that, I guess.
SPEAKER: It's upside down.
SPEAKER: Yeah, thank you. So I walk a little difficult, that is not because they tortured me to come up here but they're still sending my boots from the last RIPE meeting.
Secret Working Group report, more than 20 years of violence. These evil bastards have been around for a long time and keep pushing us into this thing.
Straight to business. Inspiration is always found by Google. So we typed it in and you can do this for yourself and what you can see will go without further explanation.
Without further words. I think that the top right one is the position that RIPE is in currently.
What do you say to a young adult when you're a parent? Still at some occasions you say grow up and that's the subject of the first Limerick. 20 years of RIPE meetings this year full of arguments, issues and beer, but it's been so much fun, we're not yet 20 one. Are we assault yet? Never. Hear hear
(Applause.) What is on the mind of a 20 years old, that's always the question. And ‑‑ but that aside, you might have seen of notice that the last few years Krasnapolsky Hotel has increased it's delicious snacks that appear in between meetings. Epicurean miracles I call them from pastry and chocolate and so on and so forth.
The secret Working Group found a strange object though, it was a weird kind of lollipop sort of cookie and that inspired one of the 20 years old virgins to ask a question: At the breaks lovely things on a stick nice and hard on the sides quite a hit but all creamy inside and it's hard to decide if it's better to swallow or spit.
(Applause.)
This is one of the worst ones yet, I must say.
SPEAKER: You were saying something about violence?
SPEAKER: Don't go there.
We all know this picture. It is depicting a future that brings large uncertainty and doubts. The secret Working Group has been aware showing this picture more often. But there is a problem. It is a data set that's been known by the community for years, but the problem we're hearing is that people have fitted models to this data set and these models have resulted in panic, ulcers and work towards global deployment of IPv6 which may be is not necessary, because you all know that statistics and models are basically lies and the secret Working Group is relatively convinced that the community has been tricked into an action that was not needed. I must say that this has been all been caused by Cobal that claims to have con sense suss and review and the secret Working Group believes that it is not true, this is a vital mistake and needs to be corrected. So the secret Working Group as a science department, I would like to introduce the science department to you.
(Applause.) And if turns out all the mathematical models that have been used previously are the wrong ones. Obviously when one seeks mathematical models one seeks complicated models and one of the most straight forward functions in mathematics was the useful one, it's the second word, polynomial. There is no need for IPv6 you can all go home. Thank you.
Can somebody call Geoff Huston? For for for for for those not used to old Latin script, this is English, please.
The massed ranks of the spamers look out, there's a posse of cowboys about, it's a father and son, please be wear when they're done, if you're Chinese or Dutch or a kraut. (Chinese, Dutch or)
I know of a father and none, preaching v6 at the point of a gun, once they had faith, but now they just hate, that with NAT they will always need STUN
(Applause.)
So most of you that have been around that is, I think, 4/5th of you giving the ratio of newcomers this time, know there are also the cultural snobs within the secret group that produce sonnets instead of Limericks. There we go. In May to sunny Netherlands we came, close by the red light district by the damn, to chatter not of earthly things or fame but ROAs routing loops and also spam all heavenly things and leading on and on to higher plains where air gets ever thin and arguments rage to and pro... but overall a smiling entity lays guiding hand and gently steers us past the rocks and shoals of network policy to land at end in harbour safe at last while Rob benevolent and even wise looks down upon us all and gently sighs.
(Applause.) (Many of you may wonder who these very cultural and eloquent works were inspired upon, or inspired by, I should say, that's shown in the next picture where the innocents have been protected. You might have seen this picture just in passing by and I know most people do not take a close look when they see pictures like this, but I want to give you the opportunity to take a close look.
(Applause.) ( I ‑‑ oh, this is really handy, you can walk over the stage and I can talk like this, but I had an experience while I was working down to the thing yesterday, normally when you walk there, there were ‑‑ people step up to you and say, you want to buy coke, I have nice pills. Yesterday there was this guy coming up saying, you want to buy TAR? , you want to buy tar? Are you looking for keys from affair, are you rootless not sure where you are, give your pusher a shout, but you better watch out, for he'll sell you a pit full of tar.
Our final piece of art, is inspired by something ‑‑ basically collaboration, we are getting much more involved as the secret Working Group in internet governance which we believe in the spirit of ‑‑ is a very good thing, even the most secret Cobals should step out and show their work. The following is a product of that:
There's a toy you can buy in the store, with the letters ICANN on the door, when you pull the string down, it sumps up like a clown, and says pick me, I'll give you some more.
So this is the toy, you see it's a little ICANN doll. How does this relate to internet governance? Very simple. For internet governance, you should pull there and the result is
Thank you. See you elsewhere, if not pressure will be applyed.
(Applause.)
Rob Blokzijl: Thank you for the nice summary of the week of hard work
SPEAKER: This is all you're going to get to take home.
Rob Blokzijl: If at least you take this home then you coming has not been in vain.
Right, I think we are at the end of this 58 RIPE meeting. I thank you all for coming. I thank the 149 people who came to the first RIPE meeting and I hope to see most of you back at all the following RIPE meetings. Following RIPE meeting takes place in October, October 5th to the 9th this year in beautiful Lisbon (LI S BON) Urgent message. Before you rush off to LI S BON, there's one report to come, you have all been using the network and you've all noticed there were a few hurdles this week, and as is the tradition somebody from the technical team will give a short report on the network service this week, at least that's what Nick told me.
My apologies.
SPEAKER: Hello everyone. Actually this was supposed to happen before the secret Working Group, but if you still need, like, a coffee would be in order then whoever wants to go for coffee, I think it would be all right.
Let's see, because this has been closed.
See, secret Working Group comes after. Actually that's not true. All right. So this would be the RIPE 58 technical summary. We're going to start by presenting the meeting team as usual, then a technical set up, the problems we've encountered and which you have noticed, some traffic statistics, wireless LAN activity and then some questions answered (LAN) we're actually in the standard team.
Ruben is part of the RIPE meeting technical team for the last eight meetings. He's leading the RIPE meeting tech team and I would very much like to thank him for the contribution he has made to the success of the last meetings.
(Applause.) (
Sheurd Alsterdyke is replacing Ruben and you might have already seen him during this RIPE meeting.
As for the technical set up, I chose this image that shows a logical presentation of our network. We're connected with the RIPE NCC offices, we're dot fiber, and the network is divided into three LANs and the routeers themselves use VRP and one is in the basement and one is in the up of the opposite room. I'd like to tell you about the problems by taking a few select among, thank you very much you know who you are, that came and reported every single bit of problem they could find. We highly appreciate that.
Mostly the problems that we have seen was even though we're coming to this hotel for quite a bit of time is because we've moved the operations room into somewhere else, at an upper floor, and mainly due to a longer e‑Net capable we started experienceing process problems with the network and the heavy load. They were intermittent on multiple fronts, they made diagnostic difficult but on IPv6 side they were a bit confusing, came from both routeers at the same time, could be related to the patch, again, one is up there and then the other one is in the basement. We did diagnostic and on Tuesday evening we took decision to disable VRRP all together and since then it was stable. The DNS resolvers at times were not reachable at the beginning and again DNS queries were traveling up the patch to the opposite room. So we bypassed that by using three DNS servers in RIPE NCC offices by bypassing that and then there have been some issues with the wireless access here in this room and probably this is the only ‑‑ the only problem, let's say, that has not been related to the patches and we solved this one by replacing all the wireless access points here with new models and reconfigureed them on Tuesday evening. By the way the stations are up 50 percent compared to the last RIPE meeting.
So all these three issues that happened almost simultaneously but intermittently on Monday and part of Tuesday, were solved by Tuesday evening. That was on the network side.
A bit on the system side. We didn't experience problems over there, but I will tell you that we have managed after several RIPE meetings to finally virtualize our server equipment and we started testing this technology about three or four RIPE meetings ago, and we never took the plunge, you know, just relying totally on it, and we keep on carrying the old physical servers with us all thes, just in case, just in case, and it worked very reliable for us. It actually allowed us to do some very neat things, such as allowing to have the RIPE meeting website up and running and updated at the same time while the server file cases are in transit flying or being set up somewhere else. And also, it has proven to be, specially away meetings, a fantastic disaster recovery solution.
Here they are, just travel with the US B sticks separately.
Let's talk about statistics, didn't have normal limits, didn't have much traffic, peak just north of 5 megabit per second. Very normal.
As for the wireless clients we had the peak of 300 users, which is a 50 percent increase from RIPE 57.
Questions?
AUDIENCE SPEAKER: What percent of traffic was IPv6 and IPv4? Could you tell?
SPEAKER: I don't have it ready. I would have to dig it up. Sorry.
AUDIENCE SPEAKER: I can comment on that. We didn't at this meeting separately set up those measurements because we didn't have the time so we don't have those numbers.
SPEAKER: Even more clear. Sorry.
AUDIENCE SPEAKER: Do your routers support getting these numbers?
AUDIENCE SPEAKER: Yes, the methods we used in Dubai was setting access lists, if I remember correctly, with counters, all traffic through and then look up the volume of the counters which only applied to IPv6 packets.
AUDIENCE SPEAKER: I thought there must be a better way but obviously not. One question: I wasn't here on ‑‑ I arrived at 9 ten or something on Tuesday morning and I know that James gave an update about the decivilians of the VRRP problem, can you repeat the D nodes of the issue again? We've seen similar things and the absence of it means you have to play around with ‑‑ I was wondering what exactly the failure mode was
SPEAKER: I think the best thing is to ask James to repeat his explanation to you.
AUDIENCE SPEAKER: We had the two routers doing the floating VRRP address and the individual addresses, so there were a total of three different routers servers coming out which depending on your client had strange effects. Juniper has a configure option to only do a router of the floater address and then v6 started worker
AUDIENCE SPEAKER: See it was sending RAs
AUDIENCE SPEAKER: Yes and depending on your stack decided doesn't know what to do, don't. You could guess an address
AUDIENCE SPEAKER: One of the routers goes down and my stack uses it.
AUDIENCE SPEAKER: Yes.
AUDIENCE SPEAKER: Excellent. Thanks.
SPEAKER: Any other questions? No. Thank you very much. (Applause)
Rob Blokzijl: Thank you and thank the team. Sorry, I now finish the sentence that was interrupted by this report. We are now really at the end of the meeting. I wish you all ‑‑ if you stay on in Amsterdam a blessed stay, otherwise for everybody else of you a safe journey home and see you at at Lisbon at the next RIPE meeting. Thank you.