These are unedited transcripts and may contain errors.
PLENARY SESSION:17 APRIL, 2012 9 A.M. 10:30 A.M.:
CHAIR: Hello everybody. Welcome to everybody, bright and early, Tuesday morning. Welcome to another Plenary Session. We'll get going because the time is tight, and I am introducing to you Ivan Pepeinjak, who will delight us with two talks, the first of which is a talk on Cloud Networking, so please, Ivan.
IVAN PEPEINJAK: Morning. You know that everyone is talking about clouds these days, and everyone is talking about clouds forgets about networking and then they launch the service and then they ask us to implement the details. So today I'll try and go into those details.
If you read my blog, you'll know that I am always complaining about some things and I have really strong opinions about some things. And the only reason for that is that I have seen too many things going wrong and too many things fail, and I see those same thing reinvented over and over and over again. So if you look at what people are proposing today, we have seen those same things reinvented at least twice before. And one of my last slides talks about an architecture that reinvents LAN.
What I'll talk about is an overview of what's available today and I will not talk about futures. So if you come to me after the presentation telling me the that vendor X has something really cool in the next release, I don't care. It's about features. And the real focus of this presentation will be does it scale? Can I use it for more than 100 servers, for example? And you know that there are all sorts of cloud services. And I have just drawn the application stack and how all these different services fit into the applications stack and the only one we really care about as the networking people is infrastructure as a service, because everything else is running on TCP. Everything else is boring. So. You'll see in the next presentation how you can build high speed networks that support the boring TCP stuff, and in this one, I'll focus on the interesting infrastructure as a service.
And there are three things we need for every cloud service. It has to scale; not, maybe, to the Amazon scale, but it has to scale. It has to be on demand. A cloud service where you sign a contract and you get your virtual machine in three months is not a cloud service. Although some vendors think otherwise and it has to be on the demand, it has to be orchestrated. I have to go to a web interface, click a few things and have it up and running, and that makes some of the things that we have been doing in the past totally irrelevant.
And before you go and you implement something, it's always good to start with some business questions. And what you should ?? well, your marketing people should be asking these questions and we know they won't. So just for the reference, here they are:
What's your real added value? Why are you different from Amazon? Because if you are not different, you will not make it.
The second question: Will you support the scale?out applications like Amazon, or will you support the existing enterprise stuff that can barely run in virtual machines and now people want to cloudify it? I don't think it makes sense, but some people thinks otherwise. And directly related to that, will you be low cost like Amazon or will you be feature?reach like, let's say, van wear. From the technical perspective, the question is: Will you offer simple computer capacity like Amazon was doing five years ago? Or will you offer tools that support the whole application stack including firewalls and load balances and virtual settlements? Or put another way: Will you be a TCP cloud that offers availability, high availability, all that stuff or will you be you UDP cloud that offers no real ability and the VMs can just drop dead like they can on Amazon when they upgrade their physical servers? They just reload the servers, though don't care about your virtual machines. It's not reliable anyway. And the last one: Are you going to IPv4 IP multicast and for whatever incomprehensible reason for me, people think that IP multicast is really important for everyone. There are applications that rely on IP multicast. I have never seen one apart from IPTV, but I am working in the wrong industry. I understand that there are some people who desperately need IP multicast, but for 99 percent of the applications, it's irrelevant. And if you focus on supporting that, then you make your life way harder than it should be.
Anyway, this is what Amazon tried to do years ago. And this is still what some people think infrastructure as a service should like like. Just look at open stack. It's not more than this. Well, now, they have Nova and VLAN, so it's a little bit better. So you just start customer VMs, you give them random IP addresses, and then, of course, the customers start complaining about isolation because I don't want to see my competitors' VM directly. So you implement some simple firewalls, and if you use Xen or KVM your life is really simple. You just turn on IP tables. If you happen to be running on VL wire, your life is hard. There are some virtual firewalls. They tend to cost a bit. They tend to run in separate virtual machines so they are not as cheap as they could be or you could go and implement private VLANs, and they are even implementible in the standard VLM ware switch. Is anyone running private VLANs today? No, there is a good reason a lot of you people are not using them. They are complex. Particularly when you want to deploy two virtual machines and they have to talk to each other. So, you need your own community VLAN to implement that and then the next one goes and asks for the same thing so you add another community VLAN and so on and so on and so on. And all of a sudden you are in VLANs. Which brings me to the next slide.
This is what most customers think they need. They want to port their existing application stack into the cloud. Does it make sense? Absolutely not. Does it make sense to port a cobble 6 application to a sand machine? It didn't make sense now. It doesn't make sense now. But people think they should do that. So they think they need virtual segments. They need load?balancing, they need fire?walling and they want unlimited scaleability. Of course this is cloud, it should scale. And they want unlimited mobility. And here on the right?hand side is the first question you should ask yourself: Will you support VM mobility or not? Will you support running virtual machines, moving from one physical server to another? That's great if you offer TCP cloud. If you offer reliability. Otherwise, it makes your life exceedingly complex.
Next question: layer 2 or layer 3 segments? There are people, imagine, who move high availability clusters based on layer 2 features in the cloud. They want to share the same IP address between two VMs in a cloud environment. There are even people writing blog posts about how beautiful that is. I mean, have they never heard of load balancers before? So, customers are asking for layer 2 sub nets. Unfortunately. And Amazon just said no. Go away. We are not doing that. We have our business model, we don't care about you, go away. And there are all other people saying yes, sure, Mr. Customer, we'll support this, we'll implement this incredibly complex network just to support your needs. And the last question is: will you implement virtual or physical appliances, and I'll just ignore that for today.
So, the moment you start talking about virtual segments someone starts talking about VLANs. That's the first reaction. And then people figure out is 4,000 virtual LANs is not a lot. Like, three or four per tenant, that's 1,000 customers. Not really a cloud service. And then the industry starts reinventing the wheel. And here are just a few more common technologies that have been thrown at us. And some some of them are theoretical. Some of them are impractical and some of them don't scale. By the way, the scaleability thing is not ?? this is symbolic, this is not up to scale. I would have to use double logarithmic scale to get from VLANs to Amazon. And whenever you have such a broad range of technologies, I always fall back on the architectural features. What is the architecture of a certain technology or solution and how does it compare to what we had before? And then you know immediately how well that will scale and VLANs are a typical prime example of stupid edge with stupid core. In voice world we call that batch panel PBXs and this is how we provision VLANs today. The server guys need a new VLAN. They go to the PBX operator, the networking guy, and tell him could you please provision under VLAN. And the networking guy takes the batch cable, well it's actually CLI, and types in the new VLAN and that's it. That's how we do virtual networkings in 99% of the cases today. In production, double quotes, cloud services.
Then the next one, OK, we have the stupid edge and we'll reinvent a smart core. Now, voice engineers have been doing that for a hundred years. Look where that brought them. Voice networks never scaled. Well they did, to a point, but look at how well Skype scales. Because Skype is using the last one, smart edge with a simple core. And by the way, speaking about stupid edge and smart core. I really like this RFC which says that if you have enough thrust, pigs will fly. Do you want them to fly? Can you afford the fuel costs? It turns out that we are throwing more and more and more money at the networking industry and ignoring the real problem, the hypervisors, hoping that the networking industry will eventually make pigs fly, and they will not. In the last part, we have people who said okay, enough is enough. Let's solve the problem where it should be solved, which I found another RFC to quote: No state in the core, the core should be stupid. That's why TCP works and X25 didn't. So, let's put all the smartness in the hypervisors where it should be from day 1, and it wasn't, because the hypervisor vendors starting with were continued with Xen, HyperV, KVM, you name it, no one ever wanted to do more than VLANs. That was good enough to prove that it works on a two machines in the lab. That was it.
So, VLANs have failed before and every two weeks I get another horror story from the field from another reader of my blog telling me how his data centre melts down because he was forced to implement large scale bridging. And eventually, it fails. The networking industry has solved that problem, no problem. In the next presentation I'll show you how a RIS a can build a layer 2 network with 19 hundred ports. And how Cisco can build a fabric path network with 10,000 ports if you wish. No one from Cisco ever said that should be layer 2, let's be honest. But, we all know that bridging has failed before and even if you run away from Span 3 and use TRILL or Fabric Path or whatever it is, it's still bridging, there is still flooding and flooding and broadcast will kill you. Remember, because of the hardware limitations, the hypervisors in the hosts put the interface cards in pro miss queue I say mode. That's the only way they can work so every broadcast ever generated on every VLAN, if it lands offer every server it will burn the CPU cycles on every server, okay? So, the server guys are happily wasting CPU cycles and we are stuck with bridging.
And then Cisco came with a great idea called VXLAN. So, we will implement layer 2 over IP. Because IP is good, right? Only, they didn't have the time to implement the control plane, so, you would need Mac to IP mapping and they didn't have time for that, and then they said well we have IP multicast so we'll just change flooding into IP multicast. Guess what? It doesn't scale. You get all this star G as it stays in the core. It doesn't scale. Finally someone came with a solution that might make sense. It's using Open Flow with Open V switches. And they still use Mac over IP, which I hate, but okay, personal opinion. And they use open flow to distribute the state into the switches. So they don't need flooding. And if you need flooding, they talk about pool nodes, which are centralised computer resource that is do the centralised flooding. And this is where the ATM LAN in relation comes in. You do remember broadcast and unknown servers, don't you?
So, rule of thumb: If you have hundreds of tenants and hundreds of servers like private cloud use VLANs, v? lands are just fine for that. Thousands of tenants, hundreds of servers, or tens of servers, vCDNI is just fine. It scales in that particular problem space. If you have few tenants, large VLANs but lots of servers, use VM aware networking that I didn't touch because it's not that relevant to the cloud services. If you have a few thousands of servers and many tenants, VXLAN might just scale but check the multicast tables on your core switches. For anything else, go with something that has a proper control plane so it doesn't need flooding.
And remember, you can always split the solution into small pieces and isolate them in availability zones and run proper layer 3 between them.
Whenever you start building a cloud service, start with the business definitions first. And when you know what you want to offer, then go and decide what the orchestration tool will be and then design your network. Don't do it the other way round. Okay.
I'll skip this.
And here are a number of podcasts and blogs that could help you get started if you haven't been doing this before. In random order, I'm not saying the first one is better than the second one or anything like that. Just Google them and you'll find them.
And that's it.
(Applause)
CHAIR: Does anyone have any questions for Ivan, at least for this first part? Randy Bush.
AUDIENCE SPEAKER: Randy Bush, IIJ. I'll just give you another quote: "VLAN: Spaghetti without wires."
AUDIENCE SPEAKER: Todd Underwood, Google. One of the things I was interested in the presentation that I didn't see cover that might be addressed in a few presentation is: When people talk about cloud computing or the scaleability of this type of computing, they often talk in an undifferentiated way as though all of the applications are going to use the network in some sort of similar way, but when you think about the cloud competing stack on the system side, but on the system side the way that the network is used is very, very different. There are some applications that will require lots of very tiny, very low latency operations and there are lots of others that are bulk transfer and sometimes it's fan in fan out and sometimes there is periods of computation, all of this. Does any of that impact the way you think about network design for cloud computing?
IVAN PEPEINJAK: That's a great question. Thank you. Actually, there are two things that I could talk about here. One is quality of service. And I really didn't want to go into that one. So if you have a generic infrastructure as a service infrastructure, then you might want to deploy quality of service to prevent certain VMs from over using the network. More or less, all hypervisor vendors support something like that today on the VM level, not going into the network. On the other hand, if you have a large fabric that supports a particular application, and it could be a load latency application or it could be a fan?out application or it could be a VDI application, then you have to know the traffic flows. Without knowing the traffic flows, the usual answer I would give you is class fabric, which is the next presentation. If you know your traffic flows, you can do better than that. But without knowing the traffic flows, no one can give you any other answer than class fabric.
AUDIENCE SPEAKER: My question is related to you referencing the fact that they are adding more complexity into the network and making it very difficult to scale, whereas if you use the end?to?end principle as we have seen in the history TCP Skype, whatever, it's much easier to scale. But I don't understand how that related exactly to cloud in the sense that what are we doing in the cloud to really make it scale from that perspective? What are we pushing into the hypervisor to make it more end?to?end?
IVAN PEPEINJAK: If you compare, like, the first half ?? well, first two?thirds of the solution space that I had there, that's bridging. VLANs, vCDNI, Mac in Mac, EVB, all that is bridging. So the core transport is layer 2 bridging and we know that doesn't scale. And as we move down from the pure transport perspective, the last three solutions, VXLAN, an ICRO and Amazon run?over IP. So, the core infrastructure scales because IP scales. We build Internet. The problem is do you have control plane that will solve the Mac to IP mapping? And Cisco with VXLAN doesn't have that yet. So they rely on multicast and multicast doesn't scale as well as pure IP. Whereas the other two, either an ICRO or what Amazon is doing internally, they don't use flooding. They use a term NISTic forwarding in the edge switches. So they have really turned the virtual networks into traditional IP application. That's why it scales.
AUDIENCE SPEAKER: So you are not suggesting more intelligence be put into the hypervisor?
IVAN PEPEINJAK: Well that's where the intelligence belongs to. So, yes, we need a solution and there are solutions out there that work where all the intelligence is in the hypervisor, and what we have in the core is pure IP transport. That's the only thing that will scale long term.
CHAIR: Okay. Thank you Ivan. And it's your turn again. With data centre fabrics presentation.
IVAN PEPEINJAK: So, this one actually answers the other half of the question from the previous one, which is how do we implement any other cloud service on a large scale?
As before, this is about real life solutions. I am not endorsing or bashing anyone. I am just mentioning what they are doing and it's about features, not futures.
By the way I got started on this track after worrying a financial block both written by James Hamilton where he claims that data centre networks are in my way and at that time, I was like, this guy is stupid. And after a while, it was like, this guy is right. So, yes, the way traditional data centre networking has been designed is not exactly optimal. Let's be polite.
Can we do any better? And will the new fancy technologies being rolled out by different vendors, all the different fabricey stuff, solve the problem? And I'll try to answer these two questions in this presentation
Why does it matter? We covered that. Cloud computing requires large scale and it's hard to do with existing tricks. And one of the questions before mentioned, we might have a totally different traffic flow in, with a new application like east?west primarily, instead of of going out to the user. And if we want to implement VM mobility, then we need some specific requirements.
And when I started talking about fabrics last year, I went to three websites of three different vendors and tried to figure out what a fabric is. And these are the answers for reference purposes. And you see that there is no overlap. So, it seems that fabric is whatever your gear is doing in the current software release, which doesn't make sense. So what do we really need?
I would love to have like James Hamilton, equidistant end points with non blocking core. Would I like to have unlimited work load mobility. I would love to have a lot less transport for storage and elephant flows like back ups, for example, and I would love to have a simplified provisioning and management. And as we go into the nitty gritty details, should it be on layer 2 or layer 3? Does it really matter? Well not if you believe in scaleable networks where you have layer 3 in the hypervisor, it doesn't matter. But if you have old school hypervisors, it might matter. Can we do this with existing gear or do we need the new shiny TRILL fabric path, SPB stuff? And it turns out we don't and it turns out the voice people have solved this 60?odd years ago when Charles Clos, faced with a problem of not having big enough crossbars, solved the problem by combining crossbars in a sensible way, and that sensible way is forever known as Clos fabrics. And we can do the same thing today because we can buy today low cost, high bandwidth switches that have non blocking performance of a few terabits. And when I talk about non blocking performance, remember, his crossbars were non?blocking because he could pass every voice call through and every voice call is, by definition, non?blocking. Whereas what we do is statistically non?blocking.
So obviously if you send two large flows over the same port, it's blocking. If you rely on load balancing and if you have only a few very large flows, load balancing will never work perfectly, so it won't be non?blocking. But generically speaking, statistically, we are pretty close, and usually, although you can build any to any non?blocking fabric, no one is doing that. We always have some over subscription on the edge. Like, 1:3 is the usual number to use but it depends yet again on your application. You have to know what your application actually needs.
And the simplest Clos fabric that you be use in the network something something like this. You have the edge switches and they are connected to every core switch so you see that there are multiple paths from switch to switch and from wherever to wherever you want to go, you always have the same amount of bandwidth available. Obviously, this doesn't work with span entry because span entry will block most of these links and you need equal cost multipath, otherwise the traffic will not be split over the links. And that means that you can either use layer 3 fabric, or you have to use something like TRILL or SPB large scale bridging without spanning tree and then as we go into more details the question is do you do full look up, full layer 3 look up on every hop or do you have this, or do you do like, Juniper is doing with X fabric, simple look up on the ingress and then it goes off to the egress port directly without any further look ups on layer 2 or 3. So, Q fabric works in exactly the same way as MPLS VPN works, although they don't use the label headers.
So here is a sample designed provided by Brad Hedlund, now with Dell Force10 and he used 36 switches to build a 10 gig edge board fabric with 1,500 edge boards and 3:1 over subscription. Not force and because this is Dell Force10, it's also in the too expensive. Or, if you use Arista, huge core switches, the 7508, you can get to 18,010 gig port in layer 3 fabric. Any to any equal bandwidth. And you can place any work load anywhere you wish, because end?to?end points have equal bandwidth between them. Apart if they are on the same type of switch, in which case they have more bandwidth. So you don't care about the placement any more.
On layer 2, as I said before, you might have to go down the TRILL path and some vendors would love you to go down the TRILL path because then they will sell you more shiny new boxes. It it turns out you don't have to. If the core switches are big enough you can use two of them and every single vendor on the market has a mechanism where two switches work as one they they appear as one single switch downstream, so you can use multi?chases link aggregation, spanning 3 will not kick in and with Arista you can get to something like 19 hundred, 10 gig ports. Does it make sense? It doesn't. As I said before, this is a single failure domain, broadcast will kill you, and remember, 1,900 server ports is like 9 hundred servers, plus, minus 1 and if you have like 20:1 virtualisation ratio, this is 18,000 Mac addresses. If you have a VDI, or something like that, with 50:1 ratio, this is 45,000 Mac addresses. Check the table sizes on the core switches. Because the core switches have to support that many Mac addresses or you get into flooding.
Some reality checks: The only use case I could find for layer 2 networks and people claim there are so many more but I have never seen them, is either virtual network segments or VM mobility. And because of the batch panel provisioning I mentioned before, usually the networking people just provision ever VLAN on every server port just to be on the safe side and so broadcast will kill you. And TRILL is very honest about that. It says we support about 1,000 end hosts in a single segment, which makes perfect sense, in that amount of hosts, the broadcast will be survivable.
And by the way you do know that VM wear high availability cluster where we really need VLANs is 32 hosts and the biggest anyone ever got to the switch is VM with 350 hosts. So, thousands of hosts in a single layer 2 demain is totally ridiculous, you don't need that. Okay.
Beyond a simple leaf and spine, we can go and build like five or three stage, however you want to call this Clos architecture. So the leaf nodes connect to the second stage, then you have a full mesh between any two stages in the middle and then the leaf nodes at the end. By the way what you see here in the middle is the architecture of every single high end switch. Every single high end switch has a three stage Clos fabric in there. Apart from a really few high end ones which use a banished network. But that's different. In the core you do the traffic distribution and still every edge has all the bandwidth it needs to every other edge.
Yet again, a sample network from Dell Force10, they got to 6,000 switches with 3: 1 over subscription, but look at this: They used almost 170 switches to implement this 6,000 ports. Someone has to [] recon/STABGT them. Someone has to wire them. Someone has to configure them. Someone has to manage them. Now, imagine that you need to add three extra switches and you already ran out of that fabric. You can go and rewire the whole thing. And that's ?? and this is not an endorsement but I really like the way Q fabric approaches this because they hide all the intricate details. What they do is exactly the same thing. Three stage Clos fabric in the middle, the first and the last stage, the QF nodes. But what they do is they hide the complexity from you. They present this as a single managed device. Is that good or bad? That's questionable. Some people are nervous having a single device with 6,000 ports. Because if that device fails, you have a huge problem on your hands.
So, I'm not saying this is the best way to design your network. But it's an option.
So, you see that we can build large scale data centre networks the way James Hamilton envisioned them, and the solution was always there for us. It has been known for 60 years, and no one was using it, well because it was too expensive, because only in recent years did we get 10 gigs which is at a reasonable price with non?blocking performance. Yet again, keep your layer 2 demains small. If you want to have a large infrastructure as a service architect, use Mac over IP, whichever vendor you prefer, and I am calls claiming that there are no need for the emerging layer 2 technologies like TRILL or SPB. Because eventually in the end we will run Mac over IP because that's the only thing that scales. But some people forcefully disagree with me. That's life.
And yet again, a number of blogs and podcasts that you can read or follow to learn more.
And that's it. So second set of of questions, please.
(Applause)
CHAIR: Does anyone have any questions on this second set of slides?
AUDIENCE SPEAKER: Hi, David Freedman. Ivan, have you seen, or what do you think of hypervisor vendors implementing MPLS inside the hypervisor?
IVAN PEPEINJAK: Everyone is forcefully opposed to that and the reason is that some people think that MPLS will fry the centre engineers brains ?? I am joking ?? so the problem is that vendors think that MPLS is not suitable to be used in the data centres. There is no reason why it shouldn't be used. The really sad part is that the broad come cheap set that everyone is using these days actually supports MPLS, but everyone claims that this is simply too complex for data centre and no, we will not do that because no one would use that. Without MPLS in the core, it's pretty hard to implement MPLS in the hypervisors unless you go for MPLS VPN straight over IP, which is that odd RFC that not many people are using. Then you get into the problem of ?? some people claim that MPLS VPN has a problem because it uses BGP as the information propagation and they claim that ?? and I'm not agreeing with that, I am just saying what some people claim, and they claim that because of that, you don't have sort of trans?sessional consistency, so you move a VM and after the VM is moved, who knows how long it will take before the other hypervisor has moved, so they claim that you need something else that will provide stricter consistency, not eventually consistency, so they are pushing for open flow in the hypervisor switches. I, for one, I am all for MPLS in the hypervisors, I just think we will never see it.
AUDIENCE SPEAKER: Are you suggesting to keep the layer 2 domain small, can you please define small?
IVAN PEPEINJAK: No.
AUDIENCE SPEAKER: Is Arnes' network small?
IVAN PEPEINJAK: The right answer is, it depends? There are two things that you have to consider when we talk about layer 2 domains. One is layer 2 domain as transport, like carrier ethernet or VPLS or DPVN if you wish. The other two is layer 2 domain in the data centres. With layer 2 domain as a transport, you usually have routers attached around it, so those routers provide the isolation. So that's not a problem. That's why carry ethernet scales. If you do this in the data centre, then the question is what's your flooding profile? How many broadcasts will you generate? How many unknown Unicasts will you eventually get? As I said before, the problem with hypervisors is that every hypervisor receives every packet because they are operate in promiscuous mode. There are people that have seen 2 gig of continuous flooding traffic in their layer 2 in data centres. That was obviously too big. The only reference I was ever able to find was the one from TRILL RFC, where they say 1,000 hosts. And 1,000 hosts in our case, if we talk about infrastructure as a service, would mean 1,000 VMs. Because the limit is really not on the physical ports. The limit is on the number of broadcasts ?? the flooding that you have to do.
AUDIENCE SPEAKER: Thank you.
CHAIR: There is a question from Jabber?
AUDIENCE SPEAKER: Hi, I have a question from a remote participant. It's from Sunny, and he asks: How do you implement QRS for different classes of traffic in such Clos networks?
IVAN PEPEINJAK: Good one. Is this a trick question? It's no different than what we do in traditional IP networks. The Clos fabric is just a particular way of wiring it together to get the opt minimum bandwidth. So, you can still use A2 dot dot 1P if you want layer 2, you can use whatever diff service mechanism if you want it to be on layer 3. What you can do depends on what the particular vendor you are using has implemented in the data centre switches. One thing I always forget to mention and that goes back to that question about fan in fan out applications, in some applications you get like a dupe classers, like, for example, you get a lot of traffic bursts going words to a single destination, and in that case from the Q S perspective it's important to have huge buffers so that you don't loose those packets. Those bursts because if you start losing them, TCP performance drops and your Hadoop cluster stops performing.
CHAIR: Okay. If we don't have any more questions, let's thank Ivan for staying on the stage for so long.
(Applause)
CHAIR: And let's move to something a bit less technical and more social. I can see Andy Davidson coming up and there is a panel on starting NOG, which is a network operators group, for those who don't know, and Andy, I think ?? I'll just hand you the microphone and you can continue.
ANDY DAVIDSON: Thank you very much. Yes, this, this is a little bit different, this panel, because we are going to be talking about a lot of the things that people might do at the RIPE Meeting and how you can encourage the same sort of thing to take place in your local communities. We are very lucky to have a panel which is assembled by people who are experienced with running various NOGs around the NCC service region. I have listed the panel guests in alphabetical order of surnames. Osama from MENOG is going to talk about the Middle East region. Paschal from Sweden is going to talk about the history of SwiNOG and what they are up to. Andrei from ENOG and Keith they are going to talk about their NOGs. We are going to have a discussion. We welcome questions from the audience and we are going to have a discussion on things that make a NOG very useful for participants.
I thought I'd begin with a picture of a map that just tries to assemble a list of all of the NOGs that exist in Europe which have meetings today. I may have missed a NOG and that means I don't know about it and that's a really good idea if you operate a NOG, then during the questions section ifs I have not listed you on the slide, then it would be maybe a good opportunity to promote your NOG to the people in the room. But, as you can see, there are NOGs broadly in many of the larger countries in Europe with regular meetings. But it would be really interesting to see more NOGs built particularly maybe in this region, because the benefit of running such an organisation, or such an event periodically is that there is so much opportunity for knowledge exchanges, so many opportunities to build business between organisations who are local, opportunity to peer with local networks you might not already and just literally share knowledge and improve the Internet so much in your region.
I have got very little more to say on the matter right now because there are some of the experts who are happy to talk. I am going to hand over first to so Sam a to talk a little bit about the NOG in the east.
OSAMA: Hello. My name is Osama, so I am the Chair of the Middle East network operating group. MENOG started in April 2007. Actually it started I would say it started earlier. It started with regional RIPE meet that a happened in our region in the Middle East, and then afterwards, with the support of RIPE NCC and the first Chair, they got together and started the MENOG meetings, and right now, we have, we have gone five years so far. Our 10th meeting is upon us. The first MENOG meeting, the MENOG 1, was in Bahrain, and then, our format is, we do two meetings per year, and we also have, within every meeting, we have tutorials. We have a conference, and we have workshops. At this stage, we have actually reached a point where we have two tracks of workshops and two tracks of tutorials, and then we have a conference, which is a two day conference. It was ?? in terms of the number of people that actually attend the MENOG meetings, they kind of vary from meeting to meeting. We actually have, typically we have 70% of the attendees being first time attendees and being mostly from the local country that we are visiting. So we have, as you can imagine, we have many countries we need to visit. We haven't visited all of our countries yet. There is five or six countries that we haven't gone to in our region. Although when we say Middle East, in fact it's not all of the Middle East. We don't cover Africa, the African portion of the Middle East, so our countries basically are the Gulf countries, and the [Lat?Am] area. Countries that we haven't been to include: Yemen, Iraq, Iran, Syria and Jordan, we have a committee, in terms of our structure, we have a coordination committee and a programme committee. The coordination committee is responsible for basically managing the finances, finding hosts, finding sponsors, finding locations of where to have the new meetings, and the programme committee is responsible for basically setting up the programme once we have decided on the location and everything is set as where the meeting is going to be.
Our committee consists of currently, these people, on the slide. I actually like to say that I think Philip was very instrumental in getting MENOG moving. He was very key in making it successful.
And I would like to say one more thing. That our next meeting, MENOG 10, is going to be April 30th, so, it's the 10th meeting is upon us. It will be in Dubai. We have two workshops. Two five?day workshops and these are extremely popular, typically. In general, the most popular portion of our meetings are not the actual conference; they are the workshops that happen either before or after the conference, and we have two days of Plenary conference and we have one day of tutorials, and the current meeting is going to be hosted by DU.
Are there any questions?
SPEAKER: I like to be more mobile. I was just wondering how this thing works.
SPEAKER: It seems to work. So, in Switzerland, three people in 2000 started to exchange some mailing lists and we should build?up something. SwiNOG, the name came a little bit later. I think it was like something like SOF, or something like that, at the beginning, Swiss operator forum, something, or SOG, I am not sure.
Anyway, then we started with a mailing list in ?? twelve years ago, and we quickly started to have meetings twice a year. The first meeting had like 15 people or something, and then it grew, it grew, it grew. After the SwiNOG 3 meeting about a year later, we started to create a kind of a core team responsible for the organisation of the meetings, about three, four, people or something, just voluntary, because the three first meetings were more like a one?man show. So, he wanted to stop and give over to, like, a group of people.
And we went like that for a while, and in 2009, we started to really think, well the idea came before, maybe in 2007, 2008, that we should create a formal association, just because of the legal entity having a bank account, being able to bill the sponsor in advance, have some safe money just in case, well tough times, we can't find a sponsor, so now, for example, we have enough money to be able to run two meetings without sponsors.
So we tried to keep the fee of the meeting quite low, about 60, or something, it's all included, and the rest is, it pays about half of the event and the rest is covered by sponsors, but we don't want too many sponsors because that means sponsor presentation, which are usually not especially interesting. Very often, product biased, so we really like to see presentation from the people, from the community to share their experience and...
So in 2012, we are going to have SwiNOG 24 and 25. 25 is in about a month. We also started to have roundtables at the end of the meeting. Sometimes more going into the legal field or so, but always linked to the technology indeed.
One thing that we did in Switzerland was, as you can see, there is another logo, which is called SwiNOG federation, so it's more complex than RIPE and RIPE NCC. We have the SwiNOG community, we have SwiNOG organisation which organises the meeting and now we have the SwiNOG federation, which acts in a completely different field because it's a federation of the ISPs, so it is representing not the techies, but representing the companies. Because smaller ISPs in Switzerland we have, like, for that small countries, about 350 official ISPs, and like, four major players, and they have their big telecommunications association and so the smaller and medium SMEs don't feel represented by this large entity, that's why we created this SwiNOG federation, we have about twelve members, so it's a start, we just started at the end of last year and the idea is to represent the member towards authorities; for example, I am participating in the discussion with the authorities about lawful interception, and also some lobbying in the Parliament. Also introducing self?regulation rules and as an idea, well budget isn't that big, but trying to go forward, acquire new members and really trying to represent the SMEs in the market.
ANDY DAVIDSON: Thank you very much. I think next is Andrei, ENOG.
SPEAKER: My name is rand re Robachevsky. I am the Chair of ENOG programme committee and ENOG is probably the youngest NOG on this panel. However, it has its routes in the RIPE NCC regional meetings similar to what Osama talked about MENOG, so the first time RIPE NCC came to Moscow in June 2004 with the first regional meeting in Russia with a goal to reach out to this first developing community, fast developing region. And at the 7th RIPE NCC regional meeting, the idea was born to make this forum more independent going on its own and form an operators group, which was quite was enthusiastically supported, in June 2011, last year, our first ENOG took place in Moscow, Russia, and in May this year, the third ENOG will take place and, this time, outside Russia in Odessa in the Ukraine. So that's a short history of ENOG.
So what's ENOG? Well, typically, it's a two? or three?day meeting. RIPE NCC regional meetings were once a year with the operators group, we thought two times a year it the appropriate frequency. More than 300 people attend those meetings. We usually do half a day tutorial before the ENOG starts. Of course we have a mailing list to discuss and announce things. We have a programme committee as every ENOG has and a committee that looks after the logistics and of course we have hosts and sponsors because ENOG, I think right now it's a hundred percent sponsored.
So, well, what can we say about ENOG? One year has passed. It has some specialties. It's bi?lingual. The conference is done in Russian and English. We provide simultaneous translation. We have RIPE day, and this is a session dedicated to RIPE, you know, update on the policy side, update on what is happening, the highlights and different Working Groups, so that's kind of RIPE coming to that region. It's not RIPE Meeting, so, for instance, no policy decisions are made but it's important that the highlights from this forum are presented and awareness is raised in that region as well.
So, when the RIPE NCC regional meeting started, I mean we had a lot of requests to get more international content and more educational content and we see these patterns changing. We see more and more local content in those conferences, dealing with global issues, as any of us deal, shall for instance, in here and other forums, so that's quite nice to see.
There are some challenges. I mentioned the mailing list, but I think mostly it's used for announcements, not enough, you know, real discussions on the mailing list, so the forum mostly now exists as a meeting, as a conference, rather than as a community, you know, interacting continuously on the mailing list like, for instance, NANOG.
I think reaching out beyond Russia and Ukraine is still a challenge. The geography of ENOG is somewhat loosely defined as former Soviet Union countries, but in fact, the geography is defined not by the actual national, but like in the Internet, by real corporation ties. We are trying to reach out, we are trying to invite people from Asian countries, from other countries surrounding Russia, and we have quite a few attendees but not a significant number yet.
As I said this time we go outside Russia, so that's first time and we'll see how it goes and maybe that will expand the scope of ENOG further.
And sustained support model: As I said, it's fully sponsored. We don't charge anyone. There is no admission fee. Anyone can attend, which has pluses and minuses, and we are thinking of maybe gradually introducing some administrative fees and looking for a more sustained model of development.
ANDY DAVIDSON: Now, Keith to talk about UKNOF.
SPEAKER: Good morning, everyone. I am Keith Mitchell, Chair of UKNOF, we have been running UKNOF since 2005, so that's seven years now in which we managed to clock up 21 meetings. We run single?day single?thread meetings three times a year. Typically, we get around 100 attendees. Recently, we have had actually more attendees than we had space for. We have mailing lists of about 800 people in that. I am quite pleased with what I call the demographic penetration, if you compare the number of attendees per population of the zone for the meeting, we are comparable with RIPE or NANOG, which is quite good. We have various of the regular components that are there. We have a programme committee. We have member organisations and board that form governance functions. We have a bunch of volunteers who always generously give their time. And the nice thing is we have a secure financial base as well.
There is a mission statement on the UKNOF website, but I like to summarise it as distribution of [] clue, and one of the nice things is that the UK is very well structured when it comes to the various bodies and associations that run the pieces of the Internet but they tend to be quite mission focused in terms of running Internet exchanges or domain registries or trade association functions. Whereas although we are very operational and technical remit at UKNOF, we have actually quite an open one as well which means we can quite wide rangeing in terms of our material. Openness is a very strong theme. We feel it's important to bring in new blood to the industry. It's also about bringing ?? a lot of people in the industry can't necessarily get to international meetings like RIPE or NANOG, so it's good to be able to bring in the speakers from other countries. We are quite good at rotating the meetings around the UK. Outside London, our best attended meetings are in Yorkshire. Like with ENOG the mailing list is mostly announcements.
Our problem is not finding programme material. Our problem is finding good quality programme material that isn't just marketing fluff. So, we have been doing quite a lot recently to try and up the quality of the material. We have some really excellent talks, but it's very satisfying like our last meeting where you don't just have one or two excellent talks but you have a whole theme of excellent talks running through it, so that's bearing some results.
Fund model: non?profit. Like the other regional NOGs, we find our funding through sponsors. Again, there is not a problem finding sponsors. It's timing of sponsors so that they are available for the meeting that you want them to sponsor and not the next one, because the next one is always already sponsored.
Costs: Reasonably cost effective. About 100 per head per meeting. There is quite a bit of volunteer time, or time that's donated by people's employers, and, again, we have managed to build?up a cash buffer which would allow us to run about two meetings without actually having sponsors.
Governance: We inherited a legal entity for governance which was a lot easier than building one from scratch. Mostly, that looks after the money. We have a board of directors that oversees that. We also thought of a bit about well do we want a membership model where we have individual members? We decided that was going to be too much work. We may yet do that, but rather than taking subscriptions or memberships from 800 individuals, we decided that the members of our legal entity would be non?profit organisations within the UK that support the Internet. So we have five of these as our founder members.
So, the next meetings: The next one is in two weeks time in York. We have set the date for UKNOF 23, which will be the 11th of October. At the moment, we are wide open in terms of where that is going to be, who hosts it or who sponsors it. And that's it for UKNOF.
ANDY DAVIDSON: Okay. Thank you very much. So now, it would be good to have a discussion about some of the challenges that you are faced when you start a NOG or run a NOG. I am particularly keen to hear any questions from people in the audience who would like to ?? who may be thinking about running a NOG for their region, and would like to ask about some of the challenges that were overcome by people on the board ?? on the panel, sorry. If there are ?? if there aren't questions I certainly have a few but I can see Kurtis has already come to the mike, so please...
AUDIENCE SPEAKER: Kurtis Lindqvist. Some years ago, this is maybe even ten years ago, we actually had what we call a Nordic operator forum that I initiated, and one of the things I have found that it very quickly became a one?man show and everybody expected me to do everything. And what's your view on how do you prevent that? How do you make sure that you actually hand over to a group that will continue to make this work because I find that's the hardest part? Setting up the NOG and getting it started is not that hard but making it create its own life and you know so you can actually withdraw and do other things is actually the hard bit. Any views on that, any tips and comments to the others?
SPEAKER: I try to stop, so far it didn't work. No, really, you are right, that might be a problem. Even when it's a group of people, okay, if one wants to stop, the whole thing doesn't stop, but still, you need to replace the function. What we do is, we are five or six people and we have with very specific functions and we have, we back up each other. Like one is responsible for the programme. One is responsible for the location, one for sponsors, and so on. So, for a temporary failure of one person, one person can do two functions. But, I mean you need to motivate the community to go to help and say okay, I want to form a group of like three people and take people with you or just try to delegate some of the work to just to someone who you know maybe. Forming a group of people is better, indeed. A one?man show can be dangerous if ?? what happens if you are sick?
SPEAKER: ENOG is very young, but I think that that's one of the issues that we we are seriously considering. There are two issues: One issue is, as I said, a sustained model of the future of this forum. Right now, it's heavily relied on RIPE NCC support from financial point of view, but also from logistical point point of view, so right now it's unthinkable of ENOG just going independently. But also on the other board is organising programme committee or organising committee. It's pretty informal at the moment. It's pretty open. We have about 15 members of the programme committee and we haven't kicked out anyone, but we are accepting new members, but, yes, those are things that we keep in mind and as ENOG develops I think we are developing the governance model as well.
OSAMA: We are in the same boat as ENOG, although we have had 10 meetings, sustainability is a big question. We are having a lot of trouble getting people to volunteer their time, put effort into supporting MENOG in terms of supporting it organisationly, and it is a challenge, I don't have an answer for that, so I don't know how to do that, how to get that done. We are just hoping through time and through more meetings, more awareness, once more people know about it, that more people will be willing to volunteer their time and effort.
SPEAKER: You can actually threaten the community. We had once the problem of financial crisis that we didn't find a sponsor, well not enough sponsors and we were not sure that we were able to do the meeting that was before we created the association, and today know we have enough money on the bank account to be able to run an event without a sponsor, just in case. But, then we just sent a mail on the mailing list and we send if we don't find a sponsor until like next week, there will be no meeting. And well we found like three. So you can try that, maybe.
OSAMA: We are not at that stage yet. We are far from that.
KEITH MITCHELL: I think it was Lyman that said within any organisation there is only ?? good people are like hard disks, they only come as new and full, and what this means is the people who are of the connections, who are active and engaged and have the knowledge and background to be good participants in supporting the network operator group, are also very busy people. So, I think our approach to that has just been well ?? I roped people in early, get them to say yes before they have to think about it. But I think one of the things we have done to recognise that people are very busy is, we have a wide supporter groups in term of volunteers, member organisations and some of the time recognise that these people will be not available and they won't be available all the time but have enough people that you can draw on the other people and have enough slack so that you are not making huge demands on every member of the team all the time. One of the things we did about a year ago was we identified for each meeting a checklist of roles and every time, a month before the meeting roughly, a monthly programme committee meetings is basically make sure that everyone of these roles is covered by a programme committee member or a volunteer or a sponsor or a member and that certainly helped to scale the meetings and keep things organised.
The other things we have done with the creation of the board is the board doesn't do a lot of it signs the cheques, it it oversees the accounts. It does the usual fiduciary duties of directors. The other main functions of the board is there to do is appoint programme committee members so that we always have a source of fresh blood in terms of programme committee. So we are still working on the formal process for that, but I think it's important to always be ready to bring in new people who will be interested in supporting the activities.
ANDY DAVIDSON: So part of the challenge is, when busy people are very busy, recognising that and allowing people to step back from a meeting or two for maybe a bit longer and making sure the fresh blood is in the wings already and learning the skills from the existing team. You say there is tan you'll process of bringing new people on, would you say? Joao.
JOAO DAMAS: I would like to ask the panel to provide a little bit more information actually on the topic of the panel starting the NOG. I have seen a lot of information of how things are running after a while, after we have gone through the initial stages, but I also ?? I'm a little bit more concerned about how you actually start the NOG in the seasons of sometimes I have seen failed efforts because too much thought goes into the initial how do we need a board? Do we need a programme committee? And stuff just get going, get things done and then let people join and which is kind of the approach we used, for instance, in the ESNOG and, yes, you have to eventually transition, you have to stabilise, but if you don't get things started, then why would you even worry about a board and all these things? I don't know. We have all different ?? we live in different regions, we have slightly different approaches on how things are done. There is a good geographical and cultural diversity on that band right now. I would like a little bit more background on people so that people who are thinking actually about starting a NOG can have a bit of a hint or an insight on how you actually started the NOG.
ANDY DAVIDSON: I think that's a good question. Secondly the in the answer is might be good to comment on what you thought your biggest challenge in the first year was if you still remember that might be a good extra thing to add.
SPEAKER: I don't know what the ?? I don't remember twelve years ago, but I think the important thing that, like, the people kicking the NOG initiative are not only from the same company. It could be ?? especially if it's a larger company, it could be seen as like a monopolistic thing trying to make something, so, most of the people have friends in other companies, so, like, gather two, three friends and say okay, we want to start that and we all have friends again, and today with social networking, it was not like that twelve years ago, but today with social networking, it should be possible to have, like, access through people, over people to people to almost all companies, all the techies in all the companies in the country, so, start a mailing list, put some people on it, gather other people, and ?? well, as a start, don't try to think at like making a board and an association and meetings. Just make a mailing list and have people start to talk on it and maybe just the community will say at sometime after a few minutes, maybe we should meet. Like, even if it's only for a beer or for a lunch, it doesn't need to be with slides or with laptops. It can just be a meeting and completely informal meeting. I think a slow start is always good, and not forcing the things tends to be better.
OSAMA: So I would guess for both ENOG and MENOG, the answer is kind of easy. It was mostly RIPE NCC support that got it moving and starting. We just needed a kind of a spark of a host to help out and that's what really got it kick?started, but without, I think without the RIPE NCC's support, and continual support, then we would not have been able to do or even start up.
SPEAKER: One of the challenges ?? that's where RIPE NCC's support is and ?? was and is very important is creating a brand. There are so many different conferences. There is so much content that brand is very important. Why people would come and discuss certain things. So there should be certain qualities of the forum you are creating but also creating a brand awareness that people will say, okay, well I'll go to ENOG, right, I expect to meet certain people because networking is very important there, not just sorting some, you know, technical problems. So ?? and that's where sustained support was very much appreciated.
SPEAKER: I think one of ?? the biggest challenge I found starting up UKNOF was push?back from the establishment. It was a case of, what do we need another body in the UK Internet industry for? And I think the lesson that we learned from that and adapted to is don't just create an organisation for the sake of it. Have a specific purpose and remit. Find your niche, where can you mate a difference? I think the specific things that UKNOF makes a difference are is that we are open and, you know, that's about open in terms of subject matter and it's also about open in terms of bringing new blood in and making it user?friendly. So, another aspect of of that is, I don't think the UK industry is necessarily all that great at training and developing people in the necessary technical skills and certainly back in 2005 when we started, there was nobody spending any money on that within the industry so kind of providing and selling the meetings is providing free training was also a good way. So, yeah, you know, have a mission, figure out what the niche is, what does this organisation do that no other organisation does. I think that's an important start?up point.
ANDY DAVIDSON: And did the mailing list come first before the meetings for the people on the panel, or did it all come about at the same time? Did you make the mailing list first?
SPEAKER: We started with the mailing list but it took two or three months until the first meeting.
SPEAKER: It was the same time for us.
DANIELE ARENA: CASPUR. My question is a bit of a follow?up on what Keith said. Where does a NOG position itself among all the other meetings, especially Internet exchange meetings? I am speaking from experience, because the Italian NOG was basically founded after a peering forum organised by all four Internet Exchange points in Italy, but after that, not much happened. Let's say there is a mailing list. Not much volume. There is a few small meetings, but the drivers of the NOG, which were the exchange points, are have turned back to being more focused on organising, let's say, their own meetings. So how does NOG differentiate from everything else that happens and network engineers are very busy, as you said, so RIPE meetings, exchange point meetings?
SPEAKER: Well, in Switzerland, first of all, the SwiNOG is really a community thing, so there is not company behind pushing it, or multiple companies pushing it. It's really a thing of the people, of the techies coming together, having fun, looking at some presentations and twice a year a day, a one day event isn't that ?? making your life too busy. It's doable. Switzerland isn't that big, so you don't need to like travel one day, have one?day meeting, travel one day. You can travelling and go back home in the same day and have the meeting. So, it's not really a problem. And it's really I think coming from the techies and there was never a company pushing or trying to get involved or anything. So, I think that makes a difference between, for example, an IX forum.
SPEAKER: For ENOG, it's interesting you ask this question because last ENOG we co?organised this with the Moscow Internet Exchange, which is the largest Internet Exchange in Russia, and it was a back?to?back event under the whole umbrella of ENOG. Agenda was different. Because, while some of the topics had certain overlap, the agenda was wider for ENOG. Also, for ENOG, it's as paschal says, it's a community thing, it's not solving a particular problem that like Internet Exchange community has, but, you know, expose a wide range of issues and being able to expose, but also to inject the spirit of open communication, a discussion of those issues, which is very important, because there is certain tendency, you know, working in kind of silents and when do you that you actually don't understand that you are missing something. So, one of the things that is also different from like very practical and pragmatic approach what we need to discuss and what we need to solve is that a wide range of issues, open discussions, this kind of thing.
SPEAKER: So, in MENOG, we are not actually focused on one specific topic; there is a range of things we try to cover, and we are pretty open. So it depends on who is coming, it depends on who is willing to speak and talk. It's kind of a free, open format, from a discussion perspective.
KEITH MITCHELL: I think the question of interaction with Internet Exchanges is quite an interesting one. We have very good support and relations with the various other regional exchanges that come up now and then in the UK. And I think one of the things is that, it's in the nature of Internet exchanges not to necessarily through any intent, that there is a certain barrier to entry. That's to do with things like having a critical mass within your ISP, having the propose routers, having the appropriate skills to do BGP, having the right engineers. One of the way to sell to Internet Exchange operators is this is where your future members are going to come from. They are going to come along the NOG. They don't necessarily know how to connect to an Internet Exchange but they will meet people, they will learn from the presentations about how to become an Internet Exchange member, and you can sell it to them as a marketing channel, which is certainly one way. And it's not just about bringing the ISPs up to the level where they can connect to the exchanges. It's also about bringing the people, you know, maybe they'll learn about an exchange and decide they want to go work for a bigger ISPs than they are working for. So, yeah, I think we have good relations with the exchange operators. I'd like to think that we have maybe helped some exchange operators get new exchanges established. That's certainly a possible position. So, yeah, and, you know, talk to people. Don't just set up from scratch. Work with all the people who are in the community and figure out how you can engage with them in a way that the be mutually supportive.
AUDIENCE SPEAKER: Hi, I am Paul Rendek from the RIPE NCC. I just wanted to kind of maybe give a bit of a message of encouragement on what's happening. I have had my fingers in a lot of these NOGs. Certainly with ENOG and MENOG. UKNOF, I have been to a lot of these. I look at what's going on in these NOGs because I poach the content and the speakers for a much larger area in this kind of multi?stakeholder arena that we are working in. I think that we no longer have the luxuries of seeing the technical community being the only ones driving what's happening or even controlling what's happening in the Internet area. I think we are moving in a much larger place. I think that NOGs can play a really crucial role in actually providing consultation to other folks that are responsible for managing the Internet in different capacities. I know that, in MENOG, inside the governments, there is a big role now where the governments are coming in looking for consultation from the technical communities in the Middle East, wanting them to actually work and provide the right consultation for them to make the decisions that they have to make. Same thing I think is the positioning for ENOG. I think that, you know, of course we would love to have everybody come to one meeting, a RIPE Meeting or some other kind of a meeting to be able to exchange knowledge, and what have you, but I think that with the saturation that we have, you can see that all the different areas have different issues that they come together and bring and I actually love that I can go to UKNOF and see what they are talking about, so that when I talk to the British Government, I can understand where you would have to go or who is the expert on where you could provide consultation. Because actually, at the end of the day, we have to understand the influence that the technical community can have in, like, the greater area of Internet operations, right. And I think that when you have these and they are successful and people go to them, you do understand that the technical community does have a lot of influence, and it needs to remains in that position. So I wanted to say that.
ANDY DAVIDSON: The other thing, maybe, about the RIPE Meeting is, if you actually look at the number of unique people that go to the national NOGs around Europe and the RIPE NCC service region, you are probably going to approach three?and?a?half or four thousand individuals. That would be a challenge even for Camilla to organise a meeting of four thousand people. There is a long queue at the microphones. I was wondering if we should move on to another question unless ??
SPEAKER: There is also a question in the RFC about...
ANDY DAVIDSON: You will ??
AUDIENCE SPEAKER: I think the burning question on everybody's mind is: why does the UK have a forum and not a group? Are you special?
SPEAKER: Because somebody else had already tried to set up UKNOG a few years earlier and basically ?? we got the names ?? if you go to UKNOG, it all works.
AUDIENCE SPEAKER: My actual question is, is a more pointed version of the last two questions: for people whose primary job responsibility, professional allegiance and interest lies in a regional or local NOG, what is your desired relationship with RIPE, with the RIPE conference and the RIPE community? What, for you, is the point of RIPE? And what would you like to ?? what is the desired relationship between your national or regional network operators' group and the RIPE community and conference?
PASCHAL: Well, a few times we had RIPE coming, making presentation, that's always a good thing. For the rest we are quite independent and don't actually need any help or support. So, I think the relationship with RIPE, for us, is mainly based on content and having like, maybe once a year, someone from RIPE coming down, making a presentation to the members on what's going on in RIPE because not every member is following every mailing list.
SPEAKER: For ENOG, as I mentioned, there is as RIPE day, which is a session, it's not a day actually, and the main motivation is to make the policy development process that takes place here more inclusive, because quite honestly, if ?? the further you go from the western Europe the less awareness of the PDP you get and PDP affects the lives and business there, so that's very important. And we keep this link.
ANDY DAVIDSON: We are about to run over, and I'd love for the people who in the microphones to have something to say and maybe, if everybody could make a comment and we make some last reflections on the comments on the microphone, that might mean we don't lose the whole coffee break, is that okay?
AUDIENCE SPEAKER: I have two comments from remote participants. Benjimin [Blakstrop] says DKNOG is only a community thing and is not pushed by certain companies or IXPs. And the other comment is from Bart, who says: I think it would be good to mention EuroNOG.
ANDY DAVIDSON: We'll maybe take that in a moment.
JOAO DAMAS: I have a complementary question to Todd's question: how does RIPE and RIPE NCC see its role as a potential sitting in the clouds to make the rain fall? How willing are you to engage and get things going supporting the small?
AUDIENCE SPEAKER: Dmitry, Hostmaster. I just want to point out that I don't see MENOG on that map. I don't know if that's an intentional omission or just an oversight?
ANDY DAVIDSON: It's my fault for not Googling a better map. So I apologise for that.
AUDIENCE SPEAKER: Anyway, another thing that ENOG I think is a powerful concept because it's the only truly regional one here and I want to thank Dmitry from making the Moscow meeting and I think there is a huge ?? and carrot in having kind of regional would be making more sense because there are so many member states. If each member had its on NOG. No want to put people in the same basket but to have organic process. Each region to have their own event.
ANDY DAVIDSON: Those questions are actually related. So there is the question about EuroNOG and the question about whether regional NOGs that are not just for one country are useful, a question about that. So, maybe somebody has some comments about that?
PASCHAL: The EuroNOG process is recurring. That's an interesting point. It comes back every few years, someone set up a mailing list and says hey, I am EuroNOG, you are all going to join, and it dies. Usually right away. It happened a few times, to my knowledge. I think recently once again, but I have usually people then tend to say, but this RIR is covered by RIPE. So, it's kind of used less and there is no involvement of people really wanting to push a EuroNOG, because they don't see any useful application for it, because you have got your national, or maybe a little bit bi?national, tri?national NOG, and everything that's on a European level, well you can come to the RIPE Meeting basically. So the people don't see any need for a EuroNOG, I think.
AUDIENCE SPEAKER: I think that regional concept is making more sense than like Pan?European concept because that's what we have these meetings for.
SPEAKER: I think it is like that. I don't invent things or I can't guess what people think, but I just see that EuroNOG's projects tend to fail.
OSAMA: On originality. I think it is complex, actually, to do something that's not national. It would definitely be much easier to do a NOG that's national where the community is closer recollect it's easier for them to get to the events. They know each other more intimately and they can cooperate more easily but when you have a large geographical coverage, it would be very difficult to go from one place to the other place and maintain that same level of support from the community because it's not really one community. It's actually multiple communities. And it's more complex to make them one community.
SPEAKER: Maybe some other thing is, and we see that a lot in Switzerland because it's a small country. We have a lot of people coming which are not helped by their employer, they take a day off, they can travel by train. They pay for themselves. And so, these local things make it also interesting that you get another audience, not only people that are sent by their employers.
ANDY DAVIDSON: We are almost ten minutes over now, so I am sorry, we must wrap it up but I can see the conversation could continue for sometime. So, maybe I might say, if there are people in the room who are interested in starting region NOGs for their region or a national NOG in a country that doesn't have one, I am happy to stay around at the front for a minute and talk further to people. If anybody is interested in doing that just come to the front and we can have a conversation. But because the break is already ten minutes in, we must wrap up. But thank you so much.
(Applause)
CHAIR: Just two quick reminders before coffee break. The first is that you can nominate yourself for the programme committee. There is one seat available and you can send and e?mail to the programme committee to nominate yourself before Thursday at noon. All info is on the RIPE 64 website and you should have received a mail.
And the second one is don't forget to rate the talks. You can log in and you can rate every talk. This is useful for the programme committee to understand how relevant the content is.
Have a nice coffee break.
(Coffee break)