Archives

Routing Working Group

6 November, 2014, at 4 p.m.:

JOAO DAMAS: Lets get started. We have to ‑‑ I would like to thank Fergal for taking the minutes. Without any further delay, Thomas Mangin from ExaBGP.

THOMAS MANGIN: Hello. Good afternoon. I am Thomas Mangin and will speak about ExaBGP which is an application which allow to do network route injection or route connection on your server.

So, ExaBGP is not a BGP, but like most application it's not a BGP Daemon. It is a Daemon, it is listening and can process routes, but its main role is not to transform your router into a routing platform. I am sorry if I repeat many of the things I said on OSS Working Group already, but the fact first 501.

Nowadays what you can do is establish or initiate BGP connection. You can parse the ‑‑ and have many RFCs implemented from to MPLS to VPLS, most I would say useful feature are already in, so if you need them, they are here. And one of the good features of it is it can be used and controlled from I would say Business Logic or other programmes.

The way I like to explain it, when you are a gamer and you want write a game, the engine makes the game. ExaBGP is a kind of BGP engine, it doesn't do the logic but allow you to build BGP applications. It is a very simple format so you can announce routes like most programmes but it's not where it is most useful. If you think UNIX and some of you probably are familiar with that, you often want to have multiple programme working together. In the case of Shell, you may very well have one first programme which will display log file and output of that will be processed by some other programmer will ‑‑ you process information and the consumer. ExaBGP allows the same thing but instead of using the PIPE principle, ExaBGP will start your worker programme and communicate with it using PIPEs, exactly like it works on the Shell line except it can be controlled, can receive command or can receive routes which have been seen on the network through that connection.

As you programme ‑‑ I would say some ExaBGP can crash as well, ExaBGP will restart your application because your programme should be a an application which will live for the whole duration of ExaBGP running time.

So what does it look like? If, for example, you get a router selling you a route like the run at the top, you can get in your application a JSON object per route, which looks like the bottom one. I have tried to collect the different packet for those who didn't like to read ‑‑ format every day and you can see what ExaBGP does is transform it in a format which can be much more easily manipulated for path application. So instead of having to deal with all the processing of the packet in and out, all you have to do in effect is now to be able to look at what you are interested in on the packet on the route and the object attribute and deal with them.

So, there is multiple ways to do so. The first one is text PI, very simple like allowancing route, prefix, next‑hop, look at preference, whatever you want. And it's you don't have to be a programmer to do that, because most network engineers are not engineer and they want a simple way to be able to do SDN or route injection or things like that. So all you have a very simple one line, one command and you can announce a route, say I want to initiate ‑‑ send a router out from ExaBGP or I want to know what is being received on the site. The newest version supports JSON which is easier to parse. The JSON transition is in progress. You can see where ‑‑ what has been received but you cannot yet initiate command using it.

So, what can you kind of things can you do quite quickly with such tool. This tool was written by one of my engineers who will ‑‑ not consider himself very advance programmer, he can programme in things like Perl or Python but is not his main job. What he has done here is just let every ‑‑ co‑router export or routing table using iBGP and started in dB that he can then use to query and generate these presentation of flows, how ‑‑ one of the aka M I ‑‑ so, there is also quite useful in the lab for BGP. Use of the first is to stress test implementation. For example, you can ‑‑ you may want to decide if implementation is able to undo very large connection at all once, to simulate peering LAN at which point you come back and every peer start to connect at the same time. To do so BGP has a feature to delay sending routes so it will start, it will load, look at configuration, load the route you want to send and wait for the time, here 60‑second. So in that example load something like 10, 21100, how many you want instances of the software, which will all at once start to generate packets and try to announce routes. So it can be used in effect to stress test and see how all the implementation are behaving.

In this case here, you can see it's a page which is a fully working programme, which will parse the BGP to announce forever random routes. So all you have got here is random routes being generated with random prefix, random MED, random look at pref in AS path which you should never see on the Internet and you probably never ‑‑ that is worst case scenario for router, there is no way to optimise of caching and can see to see how router would perform should you get very, very worst case traffic scenario.

I have implemented thing quite I would say a tricky. If you remember a few years ago we had the ASN for bug where transitive attribute was passed through the Internet to reach BGP which could not process it which was causing the BGP session to drop. Therefore, transitive can be expected behaviour and when you are want to go test hardware you will not know how software will behave. ExaBGP lets you write not only known attribute but track your own to check what future RFC draft documentation could cause your current code base or whatever you're running. So in this example you can see that you cannot place a MED of 100 but generic attribute for 080004 is MED, 80 mean optional and 64 being ‑‑ those two lines MED 100 attribute are the same and send packet on the wire and will be understood the same way by the router. You could very well add the transitive 40 value which gives you 0.0, and generate that route and see how you favour implementation under the packet. It's quite good if you want to do things which are not supposed to be done with BGP, in effect it's done and designed to pref things.

Also service announcement, it's not as useful on the core because you don't do that but may need to have service failover, service load balancing, it can be done on the core, sometimes it may be wise to not use balancers or have single failover failures ‑‑ have very good ‑‑ can be very stable, every flows if you have multiple path to some IP address the router will determine ‑‑ you got it. Always the same way. All the packets are the same host and therefore you could instead of having load balancer just use your core BGP routers whichever seeks help for that and do it on a layer, not having to have all the flows on one box tracked on one box.

You can as well announce IP address which means that you could have two serves, one I would say master slave scenario with different MED and in case of failure of the master have the IP moved, ExaBGP adds some building tool to perform check if a service is behaving as it should and should it not be as expected, issue a command to modify the route or look at pref to in effect to make sure the routing dynamically change where traffic goes to make sure the service goes to an host which has a working Daemon. There is very good explanation of those used ‑‑ by user, we have very long blogs which are very good English speakers, unlike me, I only been living here for 15 years, and give you good example, so if you are interested follow the link and have a look.

ExaBGP is when implement flow spec, for those don't know, it's a way to define flow, source IP, destination IP, product call, ports, fragment type, all those things, and trust them with BGP update or BGP message. Ways that flow definition, you can initiate action like rate limit, drop, redirect to VRF and BGP is often used in core network to provide cheap and cheerful DDoS protection like stopping DNS traffic to a known victim. It can be used, be configured to speak with Co. router and drop the traffic at the edge. It's one of the first user ‑‑ large use I heard of when I started to write software and continued to work on it as it seems to have been quite useful in many case.

This project is something do I in my free time and like every project, it competes with other things in my life. I am hoping that with time, people or change it or need some things can communicate with me and let me know what they need. There is no point writing things nobody needs in the community. Let me know, yesterday I was asked for ‑‑ configuration, there was also a partial branch with a code, and doing‑ during the RIPE meeting I added the code so now ExaBGP can decode configuration in updates. If you have need for things, let me know because I can often quite quickly do things as long as I get motivation or feedback.

If you like BGP and want to do other things and wonder can be done I keep a list of implementation available on the wiki I can be joined on this address. If you want to know more how to use it I tend to put all on my website on that URL. And that was it. And I a will welcome any questions.
(Applause)

JOAO DAMAS: Any questions.

AUDIENCE SPEAKER: So I am Thomas King from Digics, nice to meet you, we just had e‑mail conversation so far. Last year we had R IX meeting and starting a Working Group on route servers again and we quickly had a discussion about how difficult it might be to use ExaBGP to set up a route serve. Can you give me some insight into that, please.

THOMAS MANGIN: The ExaBGP doesn't have any FIB which means all it does is accept packet, decodes them, trance code them from raw packet format to JSON and text or vice versa. There is no logic, therefore the feature which is missing ‑‑ before I can become a route serverer, one would be a client to be able to ask the BGP the state of every BGP session, up or open, the usual, from every vendor. The other thing which I need we need is some internal change which will allow to change announce it to everyone with a peer, which are things which need to be done. When that is done, I think what need to be written is not an ExaBGP ‑‑ is not ‑‑ doesn't need to be an ExaBGP, but need to be that kind of look ‑‑ FIB manipulation which is doing all the routes into database or persistent storage, calculate the best path, look at what has been done and reannouncing out. That can be done in new language. Why I didn't do it I have other commitments, I promised Paul law ‑‑ version 7 support for the end of last month. And I think he is counting on it. So you must just finish first commitment to it and probably will come back to it at some point very soon.

AUDIENCE SPEAKER: One follow up, you might be interested in working, is that what you said, did I ‑‑

THOMAS MANGIN: Yes if you are willing to work on that, I welcome on ‑‑ any people wanting to do; I tend to support as much as I can, I have no issue giving you phone call, returning your call, screen sharing with you, I tend to be quite available, working in my own business it means even during office hours I don't have to justify what I do, if I want to do it I can do it, don't tell my co‑directors and it means often I can try to get a very quick ‑‑ try to get a very quick communication forth and back because there is nothing more frustrating than to ‑‑ find an issue and not be able to fix it.

AUDIENCE SPEAKER: Hello, first, I really like ExaBGP, we use it for a couple of things. Sometimes for testing, sometimes for other things. It got many new features but I am missing one feature for a long time, that is comprehensive documentation. Because every time ‑‑ yeah, I have the source code, that is actually now it's actually what I do, I go through source code, through every sample, to every WIKI page and put it, somehow, together but it's not a good feeling.

THOMAS MANGIN: I was hoping to avoid that question because I said on the OpenSource Working Group it was number one weakness of software, so I just understood that you just volunteer to write the documentation and ‑‑ I am joking. Yes, it is a weakness of software. If you want to know how to find example or working example, there is a Def for that which tend self‑testing code, if you look at the slides from last presentation, you will find where is sample of code which does work and you can use for ‑‑ for example. But if ‑‑ I am well aware it's a weak point, and I shall try ‑‑ one day when I speak English correctly I will try to write something.

AUDIENCE SPEAKER: I am sure people would be happy to translate it, you know. Thank you very much.

AUDIENCE SPEAKER:

DAVID FREEDMAN: I just wanted to give an example of Thomas's commitment to this code base by just quickly recounting, recent experience I had in a lab with a piece of equipment from a vendor that we were trying to break, and all we ended up doing was breaking our own route tester. Because the stress test that we designed were too stressful for the test unit, so we decide that had we would use ExaBGP, and the problem was that we were having difficulty scaling ExaBGP, and that is a weird thing to say; I mean, for us scaling it was running multiple copies of it many times, in many virtual machines, trying to simulate an Internet Exchange. We did it but we couldn't ‑‑ the problem we had was we couldn't breach some kind of limit of messages without ExaBGP basically sitting there and waiting for some concurrency, so we got Thomas on the phone, we had him call into the lab, and we removed a bunch of checks from the code that ‑‑ niceties to the TCP peers waiting on messages for the socket to really see the raw performance we could get out of it and we did succeed and we outperformed the route tester without thinking much about it just removing these checks. Thomas hand‑held it through and I think that is amazing.

(Applause)

JOAO DAMAS: That is it. Thank you very much. Next up is Alberto Rodriguez‑Natal.

ALBERTO RODRIGUEZ‑NATAL: Hello everyone. I am with the Technical University in Barcelona ‑‑ weather way better than London. And first of all, I will like to thank RIPE and the RIPE team because I am here thanks to them, they are paying my service fee ‑‑ thank you, guys.

Well, for those of you that have noticed, I change the title of my presentation because I have been talking with people over the week here and I realised that most of the people were not aware of what we are doing with the LISP protocol and what are the use cases of the LISP protocol so I will try to give you a headsup of what is going on on the LISP work and I hope that you enjoy it.

And if you allow me I would like to modify the order of the presentation, I will start with the questions. So, if ‑‑ so who knows about LISP can raise now his or her hand. I will appreciate it. OK. So I see say 15% of the room or even less. For those of you that raised your hand, I will be aware of any other use case besides routing scalability of LISP? Even less hands. Finally, I don't hope to see many hands now. Have you heard of the LISPmob implementation.

I hope after this presentation the number of the raised hands will change. So first, a bit about LISP and then we will move on to LISPmob. This is the very basic stuff about LISP, it became an RFC 6830, the last year, and what LISP is about, LISP stands for locator/identifier separation protocol and it tries to separate the semantics of current IP addresses because nowadays IP addresses have been used to identify host and to specify whether that host is located in the network. So LISP tries to do and this is not a novel idea but this is you see, another product seems to be working quite well, what LISP tries to do is to create two disjoint name spaces, end point identifiers and routing locateers. And these are two different are separated and in order to reach from one to the other you need to do a map and encap, which is you map, identify the and encans late, identify base packets into locator base packets.

So this is now the LISP packet looks like. So it's a standard IP address. So you have here below, a common packet that you have in your domain, and when you want to send this packet outside of your domain and indeed have to reroute to the locator space, you add a LISP header and UDP header for ‑‑ and put another IP header on top. So I will show you how the architecture goes. This is the very basic LISP architecture. So, you have the two different spaces are here on the left and on the right you have the area space, the identifiers' space and here in the centre you have the locator case and in order to reach from the identifier's space to space on the right you need to go through the locator space. So here is where most of the LISP magic is done in the tunnel routers that are deployed on the edge of the different spaces. Here you have your common IP packets, nothing special. But this guy wants to send a packet to this other guy, so it sends the packet to it's the other way and the other way tries to encapsulate it to the location of this on the right but it doesn't know where is located so first you need to ask to a mapping system, OK, I want to reach host B, can you tell me where this host B is located and in the mapping system there are a lot of research about how though make this ‑‑ stuff like that. The point is the mapping system knows that host B is located in locator Y. So it sends back this information, this information and from now on all the packets from host B ‑‑ host A to host B will be encapsulated and then encapsulated forward to host.

You can do more complex stuff with this, and I put here an example, for instance, of a bit of traffic engineering, you can define different paths over the locator space and you can say that OK, host B is reachable both at Y but also is reachable through a detour of R and then to Y. You can specify rate encapsulaters on the locator space which allows to you do ‑‑ other stuff. And the possibilities are quite many.

So here, this is one the most important slides because I wanted to point you to some of the use cases on LISP beyond routing scalability. Nowadays ‑‑ actually routing scalability is not any more a concern, the routing table doesn't matter that much. So LISP is not used any more that. This has the four major use cases. Nowadays with LISP.

So first of all, multi‑homing, because as you have seen, this is like here, it's quite easy to plug several Czechs to a single router and then map all the hosts behind the router to different paths over the locator space and those will be reachable through different paths quite easily.

Also, it's quite nice to work with IPv4 and IPv6 at the same time because if you remember, this is like here, you are not forced to use the same IP here on both name spaces so you can have, for instance, an identified space based on IPv4 and a locator space based on IPv6 or the other way around or even you can do more strange things like having, for instance, an identifier space based on strings or charters or whatever and route over the common Internet.

What else? VPNs, since LISP deploys an overlay because you have two different name spaces and deploy one on top of the other, it's quite suitable to be used to deploy VPNs and if you look at the header again, here you have, instance ID, this is used as a to identify different like attacks or you can route up over the Internet with LISP. Finally, mobility in general and especially VM mobile because if you deploy LISP on your data centre you can achieve easily to move your machines from a different data centre and they will keep the same IP and identifier over the different locations you want to deploy those machines, which is quite nice.

And this is the future, and this is my personal opinion, these ones were established or more people working with LISP agree with this, and most of the ‑‑ this is my personal opinion. I believe that the future with LISP is in these points. Actually, most of my PhD is based on LISP because since LISP allowed you to take up the control and data plains, you can push all the control to the mapping system, you can do basically stuff with LISP and some things that LISP has had a are good for DS N you can do it in incremental way, don't need to replace your network, deploy few routers and ‑‑ if you interested to this you can contact with me and I can give you a talk over an hour about that. But, moving on on this.

Also, NFV is quite a use case on LISP and ‑‑ and also as you see here, since you can deploy reencapsulating routers on your path, you can deploy service function quite easy.

LISPmob, in my university, that offers you ‑‑ for free whoever want to use it is allowed to. Nowadays we support Linux, Android and OpenWRT. And I have installed in my Android phone, if you want to check it live in the hallway I will show you how it worked. LISP devices, we are most focused on home routers and mobile ‑‑ so, we have seen more and more people using LISP over the years because we have for the last few years and we are quite happy with the community we have now.

This is architecture, I am not going to get into the details. There are plenty of arrows here and you can read my article on RIPE Labs because everything is there. But basically, we have interface to get the packets on user space ‑‑ user space implementation which gives us a lot of flexibility. Once we have the packets on we do what we want with them. Also we are starting now to provide, extract from new LISP which is a general purpose LISP library, your own application, it's up to you. So you can use other library and parse and so on the LISP packets.

So some of the features that we implement nowadays. We support the mainly RFC, for a lot ‑‑ so it's hard for me sometimes to see RFCs ‑‑ implements the main RFC and moderated draft. We support IPv4 and IPv6 so both identity space and location space. This is the nice thing we have, handovers, you install it in your phone and move away and connect from wi‑fi to 3G you will keep the same IP address. We support multihoming and you can decide whatever to do with your connections, you have several connections you can develop them, deploy them whatever you want. Especially because more devices are quite common to be deployed after NAT.

This is some of the cases we have on LISPmob on our implementation, since we don't keep track of who is downloading from GitHub, if we don't tell us we don't know know what they are using our implementation for. Please let us know. So we know that end users people have come using LISPmob for instance as easy way to have IPv6 or IPv4 and sometimes even the other way around, sometimes providers provide you one kind of IP. And this is quite cool use case. Some people are buying OpenWRT routers which are quite cheap, install LISPmob there and get two different providers which is way more cheaper than getting two different lines for single provider. And deploying multi‑homing at home with total cost about, I don't know, less than, I don't know, you can get the router for €30 and get two different DSL lines for 20. So you got for €70 multi‑homing that works quite well.

On academy, since we are quite flexible and modular, it's easy to people to get our code and to do whatever they want with it. You are aware that LISP is being used in companies as, if we are going to vendors to buy routers and whatever, they get LISPmob, they Tuesday to see if they are interested into LISP or not. And afterwards maybe they buy some big routers or not or sometimes they keep using LISPmob if the company is small.

Also, companies use LISPmob to provide quite ‑‑ a way to get LISP to end users, to the customer, so they give them a box with LISPmob and OpenWRT as router and they have their big routers on the facilities but the end user is provided with LISPmob and then they do LISP on their premises and so on.

Finally it's also used for research, so if you check papers there is some papers about it but they mention us and we are quite happy with that.

This is some of the things I would plan to implement in LISPmob because we have been talking with people using it and interested in it and this is one of the things that we think are for ‑‑ of interest for the community. And as the previous speaker said, if you are using it and you are aware of any need that you have, please let us know and we will try to implement that for you because we want you guys to use our implementation. NETCONF and YANG, and remote configuration, and inter DPDK for performance. If you were in the talk on Tuesday at 9 a.m., he is one of my colleagues, gave a talk about he is using also DPDK for performance. It's quite useful for performance. And want to implement support beyond IP and being able to encapsulate Layer 2 packets.

So this is the final slide. So please, guys, give it a try, and let us know what you think of it. You can get to our web page, it's quite ‑‑ we are more worried about the code than the web page. Get the code from GitHub and if you need to connect to the Beta network, my volunteers all over the world, if you don't want to deploy your own and want to use the LISP because it's already deployed go to that web page and contact us and we will provide you with a connection. There is no binary for because we think you can compile it yourself. For OpenWRT we provide you binaries. If you go to Google play you can find us there. There are two applications for route and non‑route ‑‑ I recommend you buy one. You have any question, I am hope to that.
(Applause)

JOAO DAMAS: Any questions?

SANDER STEFFANN: First, thank you for your presentation. Really interesting. There was one thing that I didn't agree with when you were talking about LISP in the beginning, you said it wasn't so much about routing scalability any more. I have actually seen some cases where governments are planning to deaggregate big pieces of IPv6 space and it might be useful in those cases. So, I think you shouldn't forget about that use, I think it's still very relevant.

The only thing I am a bit worried about is the way it's been developed after the RFCs have been written. I am a bit afraid of feature creep there because there lot of stuff being plugged into the protocol but the ‑‑ thank you very much.

ALBERTO RODRIGUEZ‑NATAL: Just a comment about the scalability. I agree with you, it's not out of the picture but it's not about this more being discussed and since people here, the little they know about LISP and scalability but you are correct, routing scalability is use case for LISP.

SANDER STEFFANN: Because there are situations and things, enterprises as well in the same situation, they have a big block of v6 but not all the sides are connected to their own backbone or they don't even have and you can use LISP to get the right address toss those remote sites in a very icy way.

ALBERTO RODRIGUEZ‑NATAL: LISP was designed for that so it's quite nice. Thank you.

JOAO DAMAS: I don't see anyone else. Thank you very much, Alberto.

(Applause)

So Martin now.

MARTIN WINTER: Good afternoon. So, my name is Martin Winter, I work for net Def a nonprofit company, I want to talk about IPv6 Homenet with

MATJAZ STRAUS ISTENIC: Implementation. This came after last discussion with IETF having been presented some of this work as a proof of concept and as the organisation we never get any input from the community. So look at this more like an idea giving you some hints what is going on in the home nets, if you think this is ridiculous before it's a new standard which you don't like at all. That is the whole idea.

I am not sure how many of you are familiar with the Homenet thing. There is one person, maybe a few know. If you know all the protocols that may not be much news here. I am going into the details first, the idea behind it and what it tries to solve and how. The whole idea is looking at the feature when you go towards IPv6. And if you look at the classic home network, we are not talking about geeks like you, most of you maybe at home, but the average home user. So the average home user his home network today may look something like that. He has an ISP, the Internet connected, he knows that is a box not a Cloud, so if you don't know why it's a box, look at the closing plenary of the last RIPE meeting and you will figure it out.

So basically the classic home user today for IPv4 has a set‑up like this. He has a single connection, he has like a CP device from the provider or his own one where DSL or cable ends. He may have a few wires and wireless and stuff too. In general, the average user, I assume he gets one public IP addresses and NATTed and internally has his own flat network, it's normally one segment. That is the classic home user and they don't know about routing, they normally just plug it in and supposed to be working.

Now if you think how does it go and evolve in the IPv6 world with all the more devices coming on that is where it comes in. Think about the future, now TV is going over like satellite or something, or maybe something else, cable Internet, who knows in the future maybe that moves to IP and in the future like almost like TV programmes are provided for same company but as provided as IP TV service. There are some providers out there who sell, I am not talking about Netflix, talking about the normal classic streaming programme and they may not come over the same Internet connection, they may actually, because your normal may be a DSL, may come in over the cable which they have the infrastructure anyway, just convert it to IP. So, at your home, you basically make it a second box and it has your TV is connected or like the box on the TV is connected on the Internet so you go and plug that in and you probably have, may have a infrastructure at home of some cables or don't explain the home user there are two difference, don't connect it together, keep it separate. They want to share the whole thing and the infrastructure.

So, another thing is probably phone service, voice‑over IP getting pushed more. That may be showing up there, that might be coming through the same ISP but there is more things coming in. You have a connection. Or you suddenly say hey, why have only one ISP, why shouldn't have a second one and connect things in. The home network is the normal home user can do that the idea is he can take a box more or less and plug it in and he doesn't need to worry about the whole thing. He can go and plug it in and it should work. Always we ending up with multiple routers and segments there, there may be lots of devices there and intelligent device like light bulbs or whatever, all this Internet of things, crazy ideas which are showing up there. There are a lot of things like more devices coming in and really you want to avoid the NAT issue, have global addresses and have like multiple segments and multiple routers and it just just work, that is the idea. Down there, there is a URL more like a draft which talks about use cases, different ones.

So how does it look from the IP addressing. You basically get ‑‑ I am now only talking about IPv6, basically, it doesn't really ‑‑ the plan in these standards is not really caring about IPv4, that is past, more or less.

So, it's still works as ‑‑ there are some paths on it but the multi‑homing with all the ideas, discussion there. You get from each ISP you debt DHCPv6 or something, static two‑thirds but the prefix delegation now. I assume now you have good ISPs who give you a /48. And you may get ‑‑ so these boxes will then go they will assign basically an address block on each segment there, on reach segment out from each provider. IPv6 should be ‑‑ can have multiple global addresses and basically select one. So the key thing is now then when you connect your TV, it shows which range it needs to use as a specific source and then go out to the TV ISP and the other ones too so you now have like a need for source routing tool, not source destination routing. So you have to make sure that whoever picks up an address, that the AAA arrange there goes out to ISP A, if you pick up a source ISP B and so on, that you basically go out the right places.

And so I am talking now about the different drafts and standards to give you a quick overview, so if you think other cool things or something is crazy, that is the idea then, start getting involved in it before that is all final.

So one of the few things which is already is an RFC, there is the home networking architecture principles. So this basically gives you an overview on the principles there, how you actually want global addresses for IPv6. It gives you the idea about that the need for the source destination routing thing, the router configuration because you don't want to explain grandmother how to do protocols and it also has obviously especially with IPv6, because the addresses are a little bit longer or not that easy to type any more, there is obviously name service discovery path in there which is essential. And one remark there, it's basically hit me personally, I am living in the US, I have this lovely small provider called AT&T, they give me a/62. If you think back on that thing, a few segments, it doesn't work. My home network is already too big with/62 I cannot use Homenet. So there are seem to be ‑‑ from another ISP in Germany also gives out 62s, I don't want to name anyone specifically, but really, there should be enough addresses. I mean, you can debate you may not want to give 48 out to the end user but at least give 56 please. It just makes it painful and you end up people have to do NAT again on IPv6.

So, then from the different, like protocol, the HNCP, Home Network Control Protocol, so this is the protocol which goes out and does this of the topology and the neighbours. This is what runs on all, like has to run on routers at home there, and will go discover basically all what are the neighbours out there and will go out, also assign the IP addresses. So it can discover like, hey, it knows like this one is like an uplink, where it gets like prefixes over like DHCP prefix delegation and takes that one and distributes it out. And it discovers all the neighbours there. It works, it also has to deal with how, what happens when networks get unblocked, blocked in a different way or something, how that whole thing like works when you have segmented and all that part. The idea is that this is a separate protocol, it does the IP allocation stuff, the segment stuff, the routing protocols itself not too much change. So it should be more or less giving a change to multiple different choice of routing protocol.

This one does actually IPv4 and v6, so it's mainly targeting the whole thing for IPv6 but today basically for IPv4 it more or less picks kind of random one of the first ISPs who gives ‑‑ gets like IPv4 path and does like a NAT to that so if you would have multiple provider it's kind of knot in optimal way to today, it's random which has IPv4 and uses that ‑‑.

The idea here is also that if some of the things doesn't support some of these things, you may even like discussions about having sub session on delegation in part of your network for C path too.

Then we have like in the IETF routing Working Group, we have the destination source routing path, so this is basically key thing, that is for IPv6 only the standard at this time. The idea is now that on the routing where you traditionally you only route on pure destination; now you assume that if you have a classic route with no source attributes that is a wild card source. But other than that you can have more specific sources and can say if a route is like from that specific basically source. There is also then another draft which says in which order the lookup happens there too so generally is basically you always do the longest match first for the destination and then you go start checking out for the source and you may have to go back and maybe take the less, less specific there destination. There is also a case in there, the multicast which basically all routes which have a source attributes get ignored from the way how multicast works.

There is ‑‑ that is an IS‑IS standard, so that is on IS‑IS an enhancement, now we have a new sub TLD ‑‑ TLV which is basically for the routes, so the route, an LSP basically this route, that specific source attribute only. And that space does nothing else than putting the source path into the IS‑IS protocol.

Then we have like the standards too for the IS‑IS, the way if you are familiar with IS‑IS, how it works, you can have multiple T L Vs and currently when a router doesn't support a sub TLV it can say ignore it and go on with life. The challenge is now that we have to have critical TLVs which say you can't ignore the whole sub TLV. If you don't understand that one, you have to drop the whole LSP, basically. So the whole thing is if you have a source route attached, you have a specific source only use it, you can't just drop the source and ignore it and just take it out because your IS‑IS implementation doesn't support it. So this is an enhancement in IS‑IS standard which talks about adding a feature for having sub TLVs marked as critical which means drop the whole LSP there if you can't support that path.

There is the outer configuration, obviously when people plug it in, you don't expect the grandmother to configure IS‑IS, even if you have not so much fun sometimes covering IS‑IS probably. The configuration is quite simple, pick a fixed area addresses which is 13 objecting objecting at the timing of zero, net application stuff there too. And then we have like it's level 1, there is also path on the out indication in there. It's very clear text which basically just outer ‑‑ I think it's just says outer IS‑IS or something like that, or outer cough in there, if you have any other they don't just magically form a neighbour which they shouldn't (CO N F) control on the home network.

There is also a route ‑‑ a router hardware fingerprint. That is in for duplication ‑‑ which is on the first LSP there. The idea is because unfortunately cheap home routers they sometimes end up with the same MAC addresses. And you want to avoid that you have like a conflict there because the system ID on the local MAC address based so you have hardware fingerprint is not on MAC address which they somehow generate, you see new IS‑IS neighbour comes up, is that potential conflict from someone else.

Now, if you want to go and play with that stuff and try out, see like how that works, there are like the different URLs, the Homenet control protocol, there is a GitHub. For the IS‑IS source destination, you can have the stand‑alone, down loan the IS‑IS path. If you do that, you have to get a special version of Quagga now if the C port uses below there and it's not yet completely integrated in the mainline there, it's still separate to be there. Or if you want to have a complete open W T built you can basically at the bottom there, there is a URL you can build and build your OpenWRT system. Keep in mind the IS‑IS work which we did was a proof concept, it's not in a stable ‑‑ we are working to get it in a more stable path so it may crash now at this time. It's more like to start the whole thing and look at it, how it works.

And that is basically it. So again, if you think some of this is ridiculous, strange, bad, get involved, make up your mind or something, join the discussions and give some feedback. OK.

GERT DORING: IPv6 hacker. Yeah, I have played with this and this is definitely cool stuff and made my voice heard. What I think ‑‑ what I did say but I want to repeat it again is is that I don't think that the work of ‑‑ oh Homenet doesn't support my favourite routing protocol, bring in my favourite protocol so we can all the routing protocols inside of Homenet, vendor A ‑‑ vendor CIS IS and now my Homenet is not operational. This is ‑‑ ask yourself whether this is a goal you want to pursue. I understand that IS‑IS is, two people understanding IS‑IS much more logical than using bubbles but the same would be said from OS PC crowd but still in the end if we have a Homenet that looks like IPsec where every committee put in their stuff and everything is not interoperating any more, we have failed.

(Applause)

MARTIN WINTER: To add to that currently from the existing implementation with the whole Homenet called Bable which was there from us, we did no IS‑IS, there are similar works going on. I would look at it two things: The source destination routing could be used outside of the Homenet and why not have this extension in as many routing protocols as possible.

AUDIENCE SPEAKER: I agree to that.

MARTIN WINTER: A lot of the IS‑IS, critical things, that makes sense too. The Homenet which ‑‑ that is an active discussion in the Homenet Working Group, and I think there isn't yet a consensus should be regulated to one fixed one or negotiation in how does that work or something. Right now, actually, it's not optimal if you have one OpenWRT box only do Bable and the only network existing runs IS‑IS, you plug in the Bable, the whole network will swap over to Bable because negotiation fails, that one side doesn't support IS‑IS so that is definitely a hole in the discussion still open, how do some of that the best way.

SANDER STEFFANN: I think the point you raised a Homenet needs to be plug and play. My parents need to be able to plug it in. I don't care which protocol gets picked, but pick one and make it work.

MARTIN WINTER: That is one possible choice.

AUDIENCE SPEAKER: Only choice.

MARTIN WINTER: I agree, how it works. At the end, your grandmother will not understand OSPF and Bable and IS‑IS, for her it doesn't make a difference. It has to work somehow. But the discussion really how that solved, it's going on in the home networking group and get involved and make your opinion, if you believe there should be one, then yes go there, maybe there has to be some wrestling going on. I don't know how that gets involved the best way.

AUDIENCE SPEAKER: Matthew from Amazon, although this is comments from a previous life as a last mile ISP. The CPEs may down to a price and it's really dumb and a lot of people who make the CPE are not very good at writing code. So, unless you are going to give them a really good sort of example bit of code to try, and run as a default, you are going to get some rubbish CPE and going to be even worse than you might imagine because the more stuff you add in, the least likely it is to work. We had a horrible time with IPv6 CPE, just trying to explain what DHCPv6‑PD to people was hard.

MARTIN WINTER: To add to that, that was one of the main goals getting our implementation of IS‑IS path into a good quality stuff, not just a proof of concept and it is our IS‑IS is licensed under the Patchili 2 licence in the hope most people can toss it in their boxes, the same work on the OpenWRT boxes as an example, their value have nice clean solution. Teredo Freedman just to add to that as well, I think there is a lot of vendors pulling code from Linux distributions so routing code that makes it into these distributions they are going to practically copy it, making very minor modifications if that. But this whole discussion has med me think about going into a shop and picking up a router and seeing a sticker, IS‑IS supported, a bit weird, isn't it? Thank you.

JOAO DAMAS: OK. I think the purpose of this was to ask for feedback.  ‑‑

MARTIN WINTER: Basically, don't give the feedback to me. The point was more really you see some of the different drafts and if you have some cool ideas what you think should be changed may be different or something, that's basically the ready is get involved now. Most that have stuff is still in draft, it's actively discussed at the IETF and it's time there to go and make up your opinion there, getting people explaining it, buy some of these things, it's good or bad.

JOAO DAMAS: Can I make the opposite suggestion. These people here are not necessarily all going to IETF, please convey the message. Less choice is sometimes better than more choice. Keep in mind CPE as we have just heard and I agree fully because we were doing project at ISC, they have very scarce resources, you cannot realistically have all this shit in it and expect it to work.

MARTIN WINTER: Thank you.

(Applause)

JOAO DAMAS: So, now we get to AOB and there are two possible items. First, George, if you could remember us ‑‑ remind us all about what happens when you don't do checks on prefixes across the RIR databases.

GEORGE MICHAELSON: So this is George from APNIC and I want to stress that I am not trying to speak in any sense on behalf of the members on behalf of the secretariat. This is a personal opinion because I don't have a mandate in this room. But you have heard me talk before about some of the problems we are experiencing in our region using the routing registry framework which is essentially you guys have a strong sense of ownership. It's like the cross over function with this and the database Working Group. So, what I try and do when I confront problems is I actually try and feel like what it might be like on the receiving side, so I want you to imagine that you have a large block of address and for some reason that is about your business logic, an ISP over in Asia needs to take a 24 of your address and announce it over there, and this is a business driver that is not about how you like to do your net management system in managing your framework here. They, in Asia, have the AS and they use, lets say, the JP routing registry and it has to be done in there to meet their local compliance and filter sets to work. So at some level you just have no choice, you have to let them take 4 of your address block and have it announced under some routing nobody their framework. But you have no control, none. It's done in Japanese and by Japanese people, you have no association with the agency running the routing registry, you have no opportunity to reflect on this or to give permission, in fact they can do this any time because after all, they are in the routing registry and they can assert that your address exists as an INET num and reference it in routing statement and it's out there in the world. Now, if you are in a business relationship with someone and they do this it's good because you have got money for something but if six years down the track you are not in a business relationship with them, you have no control, and they can continue to assert a route against part of your space and have an AS object associated with it and make assertions that the rest of the world will trust and you are faced with this problem, how do I get into the community in Japan and communicate with these people and say I did not give permission, I have withdrawn permission, excuse me circumstances I don't know who you are. You have no role in this routing registry, why should I believe you? Or I don't understand you. And this actually is the problem that we bring to you all the time, the classic example has recently been discussed on the NANOG mailing list, there has been quite a large amount of someone's address space being routed under the aegis of routing objects maintained in the RIPE registry because prefixes which exist inside this community, you have really good strong process control, you own the INET num object, and you control leakage of this thing with the dual authentication but you also operate in a world that says look, it would just be really a easy if I could get those addresss from Asia over here, I will let people put them in, no access control, no authentication, no permission checks of any kind, they come in and stay there forever. Zombie prefixes from hell. Because that is how the system works. So, Daniel, I think very bravely stood up and said, you know, we are going to have to talk about this. We are going to have to confront this issue, because a designer if it was done ‑‑ to have an idea of a distribution model for this, distributed data model for authenticating the presence of out of registry resource to be included in RPSL. And, you know, saying it failed in‑flight has got qualities I don't like but I think that is the reality. We don't make it work. You have to take your head out of routing and go into the database side of things. There is a real strong story in the database group that referential integrity in the database is a strong goal. Do not refer to data which is outside the schema or objects which are no instanceiation in this things, if you do, one day part of that data won't be there and you suddenly have a state which in database terms is illegal; you are referring to a thing that is ceased to exist and the entirety of the entire data model has been compromised. So from a database perspective this is really strong view, don't refer to agencies and data sources outside your own space. Don't have inferred referenced objects, don't have indirection pointer because you can't control that indirection in a database. But I think back in this room, people are scratching their heads saying there isn't only one routing registry and ‑‑ data is managed and distributed in five different places or 25, depending how you look. This is a problem that is going to have to be dealt with, and I hate to get away from the mic with a problem statement but that is where I am, I don't know what the answer is. There is a real problem here. And it's got to be looked at. Now, I can also say, oh what the hell, RPKI fixes everything, right? So there is a quality here that actually may be true. If you have a certificate over a range that is a strong crypto test where the public private key system can prove you said a thing. So I could be over in Asia and say, yeah, I give permission for this /24 or included in the RIPE database and when you see that object coming in you can test crypto and if that works that object has got my permission to be in the state. And what is more, there is a timer against it because the crypto is against a certificate and certificates have lifetimes, they have end dates, which means it can't be a ghost forever. The prefix from hell. Because the certificate is going to time out so if I stop being in the business of actually wanting this routed somewhere I could walk away and some ageing out time it's invalid and you can remove it. Or I can recommit with a customer and say you know it's annual, I am giving you an annual permit and you have to come back and talk to me for permission to use that 24 so some senses it's got some really good behaviours. And I would repeat that thing that RPKI actually isn't the answer to every problem because it can't express the kinds of policy statements RPSL is brilliant at doing, that it's not designed to do that, so there are qualities around routing registries that express things that need to be said. And that includes cross‑referencing data out of scope and say I want to insert this prefix in this limited Horizon to these people over here and I want them to let me do it and I think it's possible we could use a little bit of RPKI to make that work and keep RPSL doing the stuff that it does, the good stuff, but we have got to talk about this stuff. That is me.

JOAO DAMAS: Yes. I do like this solution a lot. The one George was referring to earlier, clearly doesn't work. If you need more than two entities to agree on anything, you will never get anywhere. There will always be differences ‑‑

GEORGE MICHAELSON: Where are we going for dinner tonight everyone, lets start voting.

JOAO DAMAS: It has been proven not to work because it's time to revive it. This feeds one into the other and using it as a source of truth, that then allows you you to put an object in there and still maintain the integrity properties that it wants to have and I think should have, is probably a good solution.

AUDIENCE SPEAKER: I really like your idea, George, it's brilliant. I think that we do need to do something about it because I have been talking about this problem for a couple of days already, I thought maybe anti‑abuse would do something about it but they declined; they said, no, talk to routing. I thought maybe the RIPE NCC may be able to do something about it but they said we don't have a mandate. I thought ‑‑ yeah, I kept asking who can do something about it? The problem has been ongoing for months.

AUDIENCE SPEAKER: Years.

AUDIENCE SPEAKER: The general problem has been ongoing since the RIPE database allows creation of route objects for space that you don't maintain. I can go tomorrow, or in five minutes, in the RIPE database create a script and basically says I own all the space ARIN has, and the RIPE database will allow me to say that and will allow me to announce all the address space from my AS number and my provider will say there is a route object in the RIPE database so I trust you. So, let me first go back to this particular problem, which started a couple of months ago, I think it was in September or maybe August, when a rogue IS number from Bulgaria ‑‑ not rogue, started announcing address space. Address space, they have never received from an RIR or an LIR. Address space that does not belong to them. And they keep on recycling blocks, they started initially with blocks from the RIPE region, not announced by their holders in BGP and basically what they did was, they used Air ADP to create a route object. For RIPE space, for their own IS number, right? So they used Air ABP which doesn't have any kind of link to the RIPE database or to the address holder and because of Air accepted the prefixes. So they initially announced, I don't know, nine to ten ‑‑ nine or ten prefixes from all over Europe. Now, we only noticed this because one of our customers was actually transferring some parts of their address space and it got hijacked during the transfer process. We thought that the transfer process would be a problem because the RIPE NCC requires you to stop the announcement before they transfer the space to the next holder. I thought initially, OK, there is a flaw in the transfer process. But it's not actually there. There might be a small flaw there but the flaw is in the way we trust IRR data. These guys, although there was a complaint made to the RIPE NCC about them, are still using the IS number and the hijacks are in progress. They just such from from a prefix to another prefix to another prefix all the time. If we look at RIS, we see that they have probably hijacked over 20, maybe even 50, prefixes, and they keep on doing it, and we are just letting them.

JOAO DAMAS: Yes.

AUDIENCE SPEAKER: So, there are two problems right now, related to this specific case: One problem would be fixed, I think, by what George said, basically the RIPE database should no longer allow anyone to create route objects for space they do not hold, unless maybe in the other registry, lets say ARIN, there is a certificate saying this size number is allowed to route, this space, and then based on that, based on that part of RPKI, the RIPE database, I don't know if it's possible, doable, but the RIPE database might then allow you to create the route object. But the second problem, I don't think we have an answer to it yet, what should we do when someone just hijacks space and they have a legitimate, according to the RIPE NCC, they might actually have a legitimate request for data number, but all they do with it is hijacking space, BGP hijacks. Should we ask the RIPE NCC to reclaim that list number, to stop doing business with that entity or just say they have that number based on legitimate request so they can do whatever they want with it?

JOAO DAMAS: That is many questions. The RIPE NCC is definitely not internet policing and has never been. What we should probably aim for, I am not speaking for RIPE NCC, my personal opinion, not provide legitimacy to anything if we can avoid it, as a community. In that sense, the imposition of new restrictions in the IRR probably is a good thing, now that we have a clearly possible mechanism to achieve that.

One of the things I mentioned earlier in the session I have been doing this stuff for 12 years, one of the things I have seen change, back ten years ago, we used to have on the agenda, the first item was review of Open Action points, and we used to have a few of them, slowly, I don't know, what happened, we stopped having those, there was nothing that was being either done by the Working Group or requested to the RIPE NCC from the Working Group. But perhaps that is what we should be doing. I wouldn't be asking of the RIPE NCC to merely doing something to change the database behaviour but I would certainly if the Working Group agrees, like to request that the RIPE NCC look at implications of changing that behaviour, and report back to us at the next RIPE meeting or earlier if possible via the mailing list because that is the mailing list is where the Working Group lives. So would anyone here be opposed to it? I think that might be a good approach to follow. I see some heads ‑‑ that is what we will do then. Thank you very much. Shane, are you going to break everything.

SHANE KERR: I am not going to break everything; I just to be clear, we are not going to charge off at a wind mile again and start down the RPSL cross registry authentication path again.

JOAO DAMAS: That didn't work.

SHANE KERR: It didn't work and then it didn't work am.

JOAO DAMAS: This is a different thing. That is what I started, that idea is dead, lets not try to revive it.

AUDIENCE SPEAKER: Poland. I am not opposed ‑‑ I am not against eliminating foreign addresses to be registered in RIPE, but we have to make sure we have different mechanism for such registrations before we block this.

JOAO DAMAS: Yes.

AUDIENCE SPEAKER: Because I have many, many cases from different RIRs and I need this.

JOAO DAMAS: I know, that is why it's allowed, we had this discussion many years ago but the world moves on and that is why the request is for RIPE NCC to think about implications about this because we don't know what we really want until we discuss it.

AUDIENCE SPEAKER: You know what I am afraid of? I am afraid that because this has become so public, it was posited on the Cisco blog and discussed on mailing lists, it's now discussed in this Working Group. I am afraid that some people do have ears and they will hear and understand the way they can actually hit the system, so I think we should act as soon as possible because, otherwise, we will end up with lots of hijacks and lots of BGP problems and, yeah, we do have to act on this because this has ‑‑ this is now public, everyone knows that you can always, if you really want it, you can always pretend to be anyone from another community in the RIPE database.

JOAO DAMAS: I agree. I also realise usually the guys are well ahead of the people who have good intent so they probably already know about this. And we should make sure that whatever we do, solves the problem but doesn't create a bigger one. Thank you. We will talk to the RIPE NCC about this and probably put an action point on them. We have ten minutes left, do you want to come up, Alexander.

ROB EVANS: I am going to point out at the BCOP task force on Monday evening, there were a number of presentations ‑‑ a number of presentations that were asking for input from routing knowledgeable people. So please have a look through the slides from the BCOP task force, there is a couple in the NANOG BCOP work that do want some input from routing folks.

Alexander: And I am going to give you a one more rapid related to route leaks. It's also have a lot of stats but very different stat. We defined route leak just the same, it announces have some kind of abnormal path. There is a provider and customer and provider and something like that. What are the main features of route leaks. They increase latency make infrastructure vulnerable and they mostly undetechable from a regional ‑‑ system. But what we can say about the amount of these routing incidents.

Here, we define not all incidents but we define the amount of abnormal paths that we detected during last months. As you can see, there are 2000 route leaks each month and we are still ‑‑ we are not satisfied by all opportunities that we have ‑‑ in our detector. But as far as concerned, most parts for the community still believe problem is far away and don't affect them at all. So this is system of RIPE NCC. And we have detected two route leaks during last three months. Both of these were death leaks, wean route leak when a customer leaks full table from one provider to another one. As you can see, these are very short life leaks. But at the same time, they are not common, they are rare. The most part of route leaks are strange one and customer leaks. First of all let us discuss customer leaks. We define a situation when, for example, your transit provider, if it's not a big one, have a global prefix list and when it's filtered out prefixes it doesn't look to the source of ‑‑ it just share the prefixes of my customer and send it to peerings providers ‑‑ and then if you are trying to disconnect from this provider in case of ‑‑ for example, stable packet drop, you won't be able to do this because it will use autonomous routes from providers, peerings or something else. And there are also a lot of, which we are defining now, strange leaks. Strange leaks is, the route leaks that could not be explained by some kind of simple mistake. For example, in this case, we detected target leak of all prefixes by Google, all prefixes by Google and only prefixes that are originated by Google. I don't think such a leak could affect Google, for example, I don't think that such kind of man in the middle attack could have some ‑‑ any affect on Google but at the same time, I guarantee that these leak has ‑‑ had great influence on latency in Russian region.

Speaking about duration. Most of leaks are short life ‑‑ short‑term. But, at the same time, more than 30% are long‑term leaks. And if they are long‑term, they are fully unnoticed.

What could you do? There are very simple, just filtering, use prefix limit but, at the same time, I think community must understand that routing incidents are not related to some hijacks that took place a few years ago. They are very popular and they make people believe, I am not related to the problem but in reality, it is ‑‑ you are affected and your prefixes are leaking now. What can be done for ‑‑ to monitor your prefixes? First of all, you can use the public available raw data and I would like to thank RIPE and route use for this opportunity. There are several projects that could give you notifications about your route leaks, route incidents, about hijacks and so on, not all of them free but it's better than nothing. And so, this is all. I will be happy to answer your questions.

JOAO DAMAS: Thank you, Alexander.

(Applause)

Anyone got any questions? I guess not. Thank you.

Well this is all for today. Thank you for coming, thank you for participating and contributing. See you all next time in Amsterdam.

(Applause)

LIVE CAPTIONING BY AOIFE DOWNES RPR

DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.

WWW.DCR.IE