Open Source Working Group session
RIPE 86
25 May 2023
2 p.m.
MARTIN WINTER: If Niall O'Reilly our first speaker is in the room, can you please make yourself known.
ONDREJ FILIP: Good afternoon, ladies and gentlemen. The time is ready for your favourite session during the RIPE meeting. You waited half a year but it's happening again, the best session here called Open Source Working Group. I don't think anybody is interested in database but just in case, it's the other room. This is open source.
Again, welcome everyone. We will have a very interesting session, as usual. But before we start, let me tell you some important words. We are at the RIPE meeting so we are following RIPE meeting Code of Conduct and also, whenever you comment on something, don't forget to say your name and affiliation and I will ask Martin to introduce today's programme. We are three co‑chairs here. It's Martin, Marcos and me.
MARTIN WINTER: We have about four longer talks and then we have two lightning talks. We start with Niall O'Reilly first, he has some interesting about EU funded framework discussion. Then we talk about peering manager, and then we have obviously the BIRD folks giving a bit of a future outlook, where the BIRD will go and fly to.
We also have the route server foundation, we have an interesting talk about what is going on there. And then lightning talk we have one more very special feature there about border, I think everyone is waiting n Bird) for that. And also there was a discussion we have this RIPE community funds which are not that well known, so Alistair from RIPE will give a quick overview on what's going on there.
And at the end, we have more Working Group organisational issues to talk about. So stick around for that part as well.
With that, let's get started.
NIALL O'REILLY: You all know that I'm Niall O'Reilly and that I have been been the RIPE Vice‑Chair for a couple of years, but now this afternoon I am wearing a different hat. I also work in with this campus company in Trinity College Dublin and we do stuff from time to time that seems A) to be cool to us and B) that we can get funding for. And one of the things that we have got ‑‑ we're called tolerant networks because my colleagues who founded the company, their first project was to do with delay tolerant networking, collecting data from wandering rain deer in the far north of Sweden and that sort of one end of the spectrum of things we do. Recently we have been doing some registrar work to support one of our projects because we needed to get hold, we needed to be managing zone files. And my colleague, Stephen Farrell, who is active in the IETF, is particularly interested in privacy and security and extensions to TLS and things.
One of the things we have funding for is a sub‑project of a programme of the EU, which is called Next Generation Internet. And this is for making improvement by supporting free and open source software development with funding. And the Brussels, and I don't know whether it's fair or not, have a reputation for having a complicated administration of share funding schemes.
So, there is a team in Amsterdam at NLnet which is not the same thing as NLnet Labs and somebody asked me yesterday to make that clear, who mediate the funding by engaging with Brussels and then announcing from time to time sematic programmes within which small teams can apply for funding. So, it's an IPv4 agile funding stream than if you were dealing directly with Brussels.
And the three actions which are active at the moment are NGI Zero entrust, NGI Zero core and NGI Zero review. The first two are funding schemes for people doing software development and the other is support scheme for helping them, giving them mentoring, doubting outreach to organisations like RIPE or the IETF to tell people about it, and that's what tolerant networks is mainly engaged in in this programme.
NGI Zero Entrust is about trustworthiness and data sovereignty and the call is open until August this year, and I don't really know much dataset about it, so go and follow the link if you want to find out about it.
The core programme is also ‑‑ that surprises me, I think I may have made a mistake with the date. I don't think those dates ought to be the same. I think they have different time lines, but you find that out on the link.
And the key questions for both of those are who can apply? And you don't have to be a company, you don't have to be a set of companies, you don't have to be based in the EU although it helps if one of the partners in your project S you don't have to be academic. The scale is between 5 and 50k euro. And the proposed work should somehow give a benefit either to the EU or to the Internet as a whole.
And NGI Zero review is the project that we're mainly involved in and that involves getting requests from any of the NGI, any of the people working in any of the NGI programmes and telling them how, if they want, how their work might fit in the IETF framework of things, or how they might best engage with RIPE or any of the other organisations that we know about.
And for the topics that we have expertise in we also give them some mentoring.
And the advice areas that people can avail of are these ones. Accessibility, diversity ‑‑ I won't read the list, you can see the list.
To find out more you can follow any of these links. And that's it. And Markus asked me how long this was going to take. I am not sure how long it actually took but I gave him a quick 30 second demo which I'll now repeat for you. There are folks in Brussels with money, there are folks in Amsterdam who can make it easier for free and open source software projects to avail of that money, and follow the links if you want to know more.
That's it. Any questions?
MARCOS SANZ: Maybe there are some questions before he leaves? Nothing? I appreciate it. Thanks very much.
Okay, so the next presenter in the agenda, and he is going to talk about peering manager, how some features develop into a stand‑alone library.
GUILLAUME MAZOYER: Thank you Marcus for pronouncing my name for the first time right. So, I am the developer of peering manager and I'm here to talk about one of the most painful experiences of my entire life, which is converting a software feature to a library.
.
So, the library in question is the IX API. We integrated a feature of IX API in peering manager for various reasons, and IX API, if you don't know about it, it's an API that makes, tries to define a common ground for IXP to manage the services and expose them to the customer. You can find out for datasets about it at the given URL.
And why did we decide to integrate that into the peering manager is a very simple reason. That since it owes customer to see what IXPs knows about them, it can also help customer into provision datasets about IXPs such as route servers, connections, auto discover services and so on and so forth.
It was implementing peer manager and it was a bit of a hack at the very beginning, it was poorly designed. I am a network engineer the code I write is shitty by design so the feature at the very beginning. So it was difficult to test, not very generic at all, and all of that trying to make it an opt inferiority and not an outout so a bit of a difficulty right here.
Peering manager already has a bunch of API to work with such as PeeringDB, which is probably the most known. And after using PeeringDB, trying to integrate IX API, trying to integrate something for this is the feeling that I had. I am in the middle of it, and this is kind of it.
Anyway, after a bit of time, and work, we decided that IX API might work need a library to work it, so, the hard work began. The idea was to simplify the code of peering manager itself for all the IX API path, but still try to have all the features, and have some kind of abstraction. So at the end of the day I created a Python package which is called PY IX API because all the Python library start with PY for some reason. And that was it. So, it tried to be easier to maintain, smaller code easier to test and it be of course reused by over projects as well.
Since I'm not a developer by myself, I am a network engineer, I tried to make that API as friendly as possible. It means it should be pretty straightforward for people to use.
So, all the hard work needs to be done automatically. So authentication, which is a bit of an issue, not an issue but a bit hard to work with, done automatically. Try to make the endpoints available or very ‑‑ in a very easy way. And try to make that consistent between the version of IX API because there is Version 1, 2, there is Version 3 coming at some point. So, that can take quite a bit of work to do.
In the end, the result is like this. So, you import the IX API. You create an API object, you authenticate with it. And then you just do some work with it. So basically four loops filtering of some services. Grabbing all the datasets for the services, for MAC addresses, for whatever, whatever data you have in the API itself.
We have a first shot at the use of the API itself and of course peering manager was a good candidate for it. So after rewriting some code of peering manager, meaning ex extracting the code of dealing with IX API itself and replacing it with codes to the library instead, we came to a feature priority at the end, and it means all read on the endpoints are working so peering manager with the help of the library can authenticate to the API of course, and also a list connections, see if you have connections not provisioned on your system but that have been provisioned by the IXP itself, discover network features such as route servers which are the most popular on an IXP, and in the next version of peer manager, which is almost ready, and by almost I mean two years from now, we have a change MAC address feature coming.
So basically you have a MAC address of your current connections. For some reason you do a maintenance on your network, you change your routers, and the router, you connect to an IXP, change the MAC address of it, change so you can automatically detect that using peering manager and peering manager will regret you to push the MAC address to the IXP via IX API, and hopefully the IXP honours that request and you get the access list updated and your connection to the ISP works once again.
In terms of the UI, this is what it looks like. So, you have what the API knows about the IXP on the top left. You have features that are available on the IXP network and you have what peering manager as a connection sees from, for the connection to an IXP. So you have the MAC address on the top of it which is the current MAC address of your connections, which differs from the one at the bottom, and therefore, you have the button to update IX API that has been displayed on the UI.
In the process of doing that, I have learnt some lessens with IX API itself because I was very naive at the beginning. I saw that you get a list of objects and then you query each of the IXs by ID to get more details of it. IX API works a bit like that but you can do more things to save time. So the idea in general is you grab all the data because unless you are big, big, big network you don't have 1,000 of connections to the same IXP, you have a few of them, one, two, three, maybe. So it's a relatively small subset of data. You grab the data, you store them in the memory and you do interpolation in the memory to correlate between each other. And for peering manager the result was a page that took like more than three minutes to load, started to load in less than five seconds in the end.
So that was a huge improvement for users mostly. And for tests because when I do it ‑‑ when I am making some tests there is a lot of requests coming up.
This is open source software, so I'm not speaking for myself here but I know that open source software is coming to all of our systems and networks and it's important to support the open source softwares.
So if you have ‑‑ because she writes some great code or shitty code but that works, just show the appreciation. You can talk about it, you can give him some money, you can buy him a beer after the RIPE meeting, you can whatever.
I'd like to thank DE‑CIX and Linx for supporting me in that IX API journey because they helped me a lot with it, and especially one of the guys who is probably not here which is Catalin which helped me a lot in working with IX API.
And with that I think I'm done, so if you have any questions, I am here for it, or after the talks.
.
(Applause)
ONDREJ FILIP: Are there any questions? Some questions in Meetecho? No. Excellent. I think that was clear. Thank you so much.
The next speaker is a man with a very beautiful first name, I think that was the reason I was chosen to introduce him. His name is that, and he is one the BIRD developers and he will talk about the overview and future outlook.
ONDREJ ZAJICEK: I will speak with BIRD 2. BIRD 2, there is some history of BIRD. I think I don't need to introduce BIRD but just for the remote possibility that someone does not hear about that, this Internet routing demon software which is used by most Internets in the world and probably can be used outsource routing software on wide box routers or PCs so implement BGP, OSPF, and so on.
So, first some history. The BIRD was originally started in the year 2000, and the first official release of BIRD was in the year 2000, but after that some kind of student project, but after it was released and it's some kind of slum better form and it was something in the year 2008 as the project of cz.nic and the first release under cz.nic was the release of version beta 1.0.12, and after that we developed a new version, get new users. But we have ‑‑ we had some kind of constraint by original design of BIRD, which has some kind of strange design decision that IPv4 and IPv6 would be completely separated, it would be compile time option then you have to compile BIRD with IPv4, compile BIRD with IPv6 and it doesn't really know whether to use IPv4 or IPv6, so it cannot be used for things like multiprotocol BGP, it cannot be extended for many other NLRIs in BGP. It works for basic configurations but it has some kind of upper bound for what we can implement in it or not. So we started to work on the integrated version, and in the year 2017, we released BIRD 2, which was the first integrated version. And as you can see, there is also the BIRD 1.6.8, which is the last official released version of BIRD Version 1. So it's in 2019.
So you can see now, this is 2023, so last version of BIRD Version 1, is about four years old, and we currently plan to release BIRD 3 hopefully this year, but that will be that I get later.
When I speak with some people here, I ask which version of BIRD do you use? And in many cases I still get answer like: We use BIRD 1.6, we don't really need these integration features, we use separate BGP sessions for IPv4 versus BGP investigation for IPv6. So, why should I upgrade to BIRD 2? I think I should make it some kind of sales pitch why you should upgrade to BIRD 2.
So, when we release BIRD 2, there are some overt features of BIRD because of the new design. The new design comes with integrated IPv4 support. So it allows to handle multiple network types like IPv4, IPv6, VPN, v4 and v6, full spec. It allows things like extended things of ‑‑ you can have IPv4 route with IPv6 next hop or vice versa. It allows to implement MPLS labels and switching rules. All things that are supported in BIRD 2. And also multiprotocol BGP transfer sessions from IPv4 to IPv6 path.
But there is also covert changes which happens completely unrelated to these changes, to these multi‑protocol design decisions that are only in BIRD 2 and not in BIRD 1. And I think these are, each of these points is important enough to upgrade.
So, we have a route table has improvement. The original BIRD 1 was designed in the year 2000 where full BGP table was about 300,000 routes. Today Sister more than 900,000. So in my test bench marks, got some result that the simple hash lookups in routing table in BIRD 2 is about six times faster than in BIRD one. So, this is the first point.
The second point is the origin of BIRD 1 used timers for greater than one second. Every time keeping is done in one second. So in BIRD 2 we have micro second timers which allows better log messages, allows more precise time keeping.
The third point is the bit maps of exported routes. That's some cryptic point which is mostly that when we export some routes through BGP, we have to keep some way the information whether we exported it in case we have to evolute export filter and decide whether we have to withdraw that route Tor we can just ignore the change. And that was done in some kind of implicit way in the BIRD 1. When we changed the exporter we avoid the old filter and the new filter and compared those results and there is many corner cases that we may get wrong, sometimes we get wrong and in BIRD 2 we changed that. We keep that information explicitly with maps, so it is faster and it is not prone to errors. So that's the next improvement.
And last ‑‑ one of the last of these things on this slide is the improved kernel interface. That's important things because kernel API changes, it should not change, but there are some semantic changes that causes that with the newer kernels the old BIRD is much less effective. They started to push some error messages in net link which causes much more traffic on the net link and we have to do some changes to filter that and so on.
So, if you ‑‑ so if you need a good kernel interface, if you push your routers from BGP, from BIRD to kernel net link, you also need.
There are also significant filter improvements. We have a complete redesigned interpreter code from some nice implementation to byte code interpretation, which is faster. We have much faster prefixes in BIRD 2 which are the structures keeping prefix filters. We have static type checking which means that if you have some filtering implemented in BIRD configuration, that has some time errors, that in BIRD 2 you get error message when you try to load it, in BIRD 1 you have the front time error message in log that the filter is found invalid in the situation. So it is much easier to check.
We improved the defiltering where some features to make it more like a programme like for loops, for recursion, local labels. We implemented that custom route attribute. So in your routing table you can define new kinds of attributes with different types and assign values to them in filters so you don't need to put your information for example in BGP communities but you can define your own attributes and use them.
And we have improved error messages.
.
Okay, there are also many new features in BGP, which are in BIRD 2 not in BIRD 1, such as import/export tables which is in and out tables from the BGP standard which were not implemented in BIRD 1.
Several new features, I already mentioned extended next hop. DHCP confederations, I don't know if you know. Dynamic BGP, that allows you to add e.g. P method for route packets to external BGP so you can get optimal routing through metric and multiAminex internal BGP, BGP hops.
There are some new features, BGP roles which is some new RFC which is formalise the provider peer role to the BGP protocol, so you can declare this session is to provide this session is to customer and you have automatic filtering so you don't leak your routes you receive from one provider to the second one just because you have fixed filtering in your export filterings.
Then we have dynamic BGP which is features to allow receive as many BGP sessions without need to explicitly configure them.
We have completely redesigned RPKI in BIRD 2. So, a ROA records are just another kind of network type. In BIRD 2 it's not special structure like before. We have standard RPKI‑RTR protocol so you can download records from a cache using standard protocol, and we also have automatic router validation. While in the BIRD 1, the RPKI handling was just kind of some preliminary. To that's another reason to use BIRD 2.
There are also new OSPF features like authentication, graceful restart.
We have Babel. In BIRD we have Babel, we are developing Babel routing protocol which is something like we have done right. So, it's used on wireless networks and BIRD 2 has many improvements like authentication, also the feature of external next hop like in BGP, it's so specific routing you can have multiple routes based on the source of the IP address.
And the most importantly BIRD 1 has end of life. We decide that we do not make new releases after 2023, so I would suggest everybody to upgrade to BIRD 2.13.
Some people say they didn't like the split design, but you can run BIRD in split design 7. In BIRD 2 you don't have to configure everything in one stance, you can run in two densities of BIRD, configure for IP for another IPv6 if you like the old spread design you can do the same in BIRD 2.
And there is some URL with some notes how to transition from BIRD 1 to BIRD 2.
And now I will speak about BIRD outlook, which is the new features we are developing for BIRD. We plan to, we are working on it and we will probably release them this year, business BGP monitoring protocol, that's like many people asked us for. We already have some very, very preliminary version in the last, in the latest BIRD 2.13. But I hope we will get some very final version in the next version.
The next thing we are looking for is MPLS/L 3 VPN with ‑‑ we also preliminary called in BIRD today but we want to improve it.
BGP validation AS path using AS PA, I don't know if you know what this is, but since I don't have a photo of it, BGP part of hijacks and some support it and so on.
So, next thing is BIRD 3. We are also working on BIRD 3 which will be a multithreaded version with BGP and RPKI and pipe and other protocols because it's 2023, so having software transfer single core when you have to manage 20 gigabytes of routing that is not optimal, so that's something we like to have to improve performance especially in a very significant set‑ups like Internet exchange points. We also have Asynchronous route experts in BIRD 3 and that means that we also do ‑‑ avoid some issues with that are not BIRD 2. And completely designed import/export tables to do some better and more efficient way.
So, we already have about three of our releases, so if you want to try it, please get it from over the web and try it on your setup and report if you have some crashes, if not, then also please report your experience with it.
I have some graphs of performance improvements of BIRD 3 compared to BIRD 2 from my colleague Maria, so, these are essentially a graph of 600 extension points of 650 clients about and convergence times of number of routes. You can see this is ‑‑ so there is something like six times faster with 10 cores, if I remember correctly.
If we have 5,000 BGP sessions, we still have some significant improvements in convergence time. You can see that from some number ‑‑ from some size limit, it is not really possible to conclude it in V2, but we can still get to v3.
And I will also note that we offer support service for BIRD with ‑‑ a support package with guaranteed response time, training services, product integration and development. So if you want ‑‑ if you need some technical support, you are guaranteed parameters, please ask us.
So, any questions?
ONDREJ FILIP: Questions?
AUDIENCE SPEAKER: Hi. My name an Alexander, first of all, thank you for these great work on BIRD Daemon, especially speaking for myself, it's my most favourite open source software. I have a few questions according to your plans.
Do you have any plan to implement ISIS?
ONDREJ ZAJICEK: We said that well, we have plans to implement ‑‑ we had plans to implement ISIS for many years but these plans never realised so I wouldn't say we have plans to implement ISIS, but do you have some need for it?
AUDIENCE SPEAKER: We are using it.
ONDREJ ZAJICEK: Okay, that's a good point. Perhaps we can think about it more.
AUDIENCE SPEAKER: And the second question is: Also related to the way we're looking currently for the flexibility, and there is a lot of work to integrate BGP and Daemons with some code to have some pipeline to get routes from the software and insert routes on certainly reasons into the software. Do you have any plan to have a kind of a way to interact with the BGP Daemon?
ONDREJ ZAJICEK: Yeah, I did not mention this because that is subject of the Maria's talk in the lightening session, so I probably would not spoil for you much if I say yes. But it will be answered in the lightening session.
AUDIENCE SPEAKER: Okay. Thank you very much. Thank you for your comments and work.
AUDIENCE SPEAKER: Alex Band for NLnet Labs, a couple of years ago we started a couple of brand new projects and we were like are we going to do this in C or are we going to adopt a very safe language? And we feared that doing that in 2019 would be a good idea. And since then was sort of within the industry, there's been a lot of focus and a lot of traction on adopting memory safe languages so now we're getting a lot of requests, so are you doing this for your procedure projects too? And I was wondering where you are getting similar requests and whether you have any plans in that area?
ONDREJ ZAJICEK: Well, it is probably not a good idea to rewrite the project completely so I hope that there will be some way to improve safety of existing code in C through some kind of additional code to validate for example for buffer lines sort of things like that. With you DOH didn't find anything that could be easily adapted to the existing code base so I don't plan to rewrite it from new. But yes, I would like to improve ‑‑ to use some more safe time system inside existing code base but I don't see much usable tools for that.
AUDIENCE SPEAKER: Marcos Sanz from DE‑CIX. One of of those big BIRD installations we completed our migration from BIRD 1 to BIRD 2 last year, and in all or locations and if we just look at the front Board installation one we used the ‑‑ bring up the cold start of the software from 50 minutes to 25, just by upgrading, and even more impressive, the memory consumption was reduced by 1 order of magnitude from 50 gig to circa 4 gig at the moment. So I just want to tell you and Maria and the whole Cz.nic team, great work.
AUDIENCE SPEAKER: I first I want to thank you for your great work and the great presentation. In our we use BIRD and we passed output from your CR I and socket so I want to ask does BIRD have any plan to imply something like a GAPC or just an output to make the thing easier?
ONDREJ ZAJICEK: That's actually a question I get, that it will be a subject of the Maria talk in the lightening, so, yes. That will be in the lightning talk next.
ONDREJ FILIP: Okay. I see no more questions. Okay. Thank you very much.
(Applause)
NIELS RAIJER: Thanks everybody. Thanks for having me here.
This is us. This is the team. There are some familiar faces and maybe some unfamiliar faces but I can assure you everybody is working on developing route server software here, and I can tell you already we have just listened to BIRD. Well we are the competition. We are open BGPd. So just so, you know, this is a battle.
No it's not, I will explain. I myself have a lot of affiliations but the next 15, 20 minutes I'll be talking to you with my hat of the Chairman of route server support foundation. One affiliation I do not have, unfortunately, is that I'm a good coder, because I'm not, I can do some Python scripts and of course the obligatory ten print on my Commodore 64 but after that, there is nothing more. So I do not contribute to the open BGPd code myself and we should consider that a good thing.
What is RSSF? This is a formal body. It is a foundation and it is a Dutch foundation, so the words that springs to mind in that case is now, close your ears ‑‑ Stick ding.
Why did we choose to be a formal body? Because it was time for our four founding members to have some official kind of way to support the development of open BGPd. The four founding members are DE‑CIX, NetNod, Linx and AMS‑IX and the goal that they sought to find with our foundation is to diversify the route servers, the diversecation is because, as we just heard, BIRD is being used on many, many, many Internet Exchange points, and maybe it is good if BIRD was not the only one on those Internet Exchange points and not just for us so we can develop noise software but it's also probably better for BIRD if the whole Internet does not depend on their presence in their development.
There were some challenges using open BGPd as a route server on big exchanges like the four mentioned, and that meant that we had to start the project to scale to thousands of peers and implement some features that the IXPs needed so there would be feature parity between open DHCPD and BIRD.
There was also support from JPNAP and ISOC and since last year we also have NL‑IX on board as a supporter. And we don't just do open BGPd, we also offer support on RPKI client which is what every network also needs these days of course. And I will get back to why that is good for us and why we think that this is a very good idea actually.
.
Now, this is a bit of fun. It's a screenshot that I took touring one of the first meetings that we had with the four founding members and at the time Marcos Thomas was still in the Board, and he was asking yeah, but how are you going to structure the foundation? And yeah, we were thinking, we should maybe get a structure in place. And before we knew it, and maybe you know the feeling Marcos, but Thomas is very good with PowerPoint. So he had this done in a couple of minutes. Hold it against him if you can. Anyway, what happens is that RSSF consists of an Executive Board that does the day to day business‑like keeping everybody doing their coding and participating their bills basically. And that is the three guys on top of the photo that you just saw.
And then the actual work is being done by a project manager and the developers that we hire. There is an advisory board with people from the four big Internet exchanges in there that we meet every quarter and they oversee our Executive Board, they oversee what we do. And then of course there is a technical advisory board with people from the Internet exchanges and they discuss with us what the technical advances are and what they maybe should have been, and Thomas called that geeks.
The technical advisory board wi‑fi a meeting next week during more IP, I don't think it's the idea you will just freely join but if you have any technical stuff to discuss, then find me or Job and we will be happy to talk to you anyway.
What do we not do?
.
RSSF does not have a secret agenda to shoot the BIRD. Because, as we just heard, everything is fine with BIRD. There is nothing wrong with it. We don't compete with BIRD. We don't want it in a cage. We just want diversity on Internet Exchange points. So we need a second route server that is good enough to run those big Internet Exchange points.
In the beginning, because we exist as a foundation now for three years, four years. In the beginning people were asking are you going to fork open BGPd? No we are not the Internet exchanges and other supporters are providing funds and we use those funds to develop features in open BGPd that everybody needs capabilities that everybody needs, one important one I will get back to a little bit later. So, there is no intention to fork open BGPd and have some kind of secret route server. Should stay inside the Secret Working Group if it would be a secret route server, so it's the wrong Working Group in that case.
The IXPs have quite some developments. Of course it took sometime before everybody was on board with testing and having their programmes modified to talk to open BGPd as well as to BIRD. So, it took quite some testing with APIs and everything and then most of those exchanges, they also have smaller peering LANs, elsewhere in the country, I don't know DE‑CIX, for instance, has one in Dusseldorf which is not as large in Frankfurt and you have one in Hamburg which is not as large as Frankfurt. So that's why it's ideal to test but I am also happy to report that Linx told us that online 2 LAN, so the secondary 2 LAN peering LAN is also running on BGP with BIRD running on the primary peering LAN. And we believe that we are on track for the introduction do it of open BGPd on other large peering LANs next to BIRD. I will say this once again, not in place of BIRD but next to BIRD because we want that diversity.
And if you run an Internet Exchange and you would like to discuss how to do open BGPd next to BIRD, again come to me or come to Job and we will discuss.
Of course, everything is in here is open is I am sure everybody is subscribed to the announced mailing list of the best operating system, and you have already seen the open BGPd 8.0 release announcement two weeks ago. This has some features that were developed by request of our supporters.
I'm not reading everything out because the e‑mail was actually longer than this, so there's more, but you can find it out yourself. And the same going for RPKI client. It's also been a new version released a couple of weeks ago and this e‑mail was even longer and the fond would have been so tiny that you wouldn't even see any more than was in the e‑mail.
So, trust me, new software is being released and it's being released in the open. There is nothing secret here.
One thing that I would like to mention is that out of the blue, we were contacted by a German organisation calling itself the Sovereign Tech Fund, and they were telling us that they were doing a pilot project and they wanted to distribute some money to open source projects and they were wondering if we were interested. We were interested. So we outlined three bits where open DHCP D could use some improvement, but there were like conditions because it had to be done in a certain time frame and it it had to be measurable and everything. So we set out to state we want ASPA support in open BGPd. We want to improve the route decision engine performance and we want to improve the support for Linux and it's funny to have just heard from the BIRD team that two of these are also ‑‑ all three are actually on their agenda. That's pretty funny.
So, we said yes. Give us the money and then we will start to develop. We did that. We were able to hire an additional developer actually. So that was a pretty good thing because that could have been a showstopper if it wouldn't happen. We received the funding and we developed.
Now a couple of weeks back I went to Berlin for their pilot round evaluation conference, and we were there with the projects that they funded which was two handsful of projects, maybe a dozen projects were funded and the developers of most of those projects were there. And we had to evaluate how the pilot round went and what the software tech fund could have done better and there was some food and drink and it was nice to meet other software developers.
What we found out at that conference though, and that is actually something I wanted to give to you as a room with people interested in open source, is that it seemed that me as a foundation were really ahead of the game because we have an organisational structure, we have a Board, I mean I am the Chairman, Job is the secretary, we have a treasurer. We employ people. So we pay them fixed monthly wage. They have health insurance. All those others were like wow! And, you know, I like to tell the story that I used to be a young and naive and probably today I'm only still naive, but I was always thinking that all these wonderful software that I use everyday is being made by people in their attics in their spare time. Well it's not and of course I am preaching to the choir here but once you explain to people that open source software does not mean that it is all volunteers. Those people have families, they have mortgages, they need to be paid, and what they want is continuity. And that the pilot evaluation conference in Berlin pointed out that this is really what the developers are looking for.
I must also say that while the pilot round started pretty easily, Job and I just hacked a small document together saying what we wanted to do and we sent it in and we received money, and they said no, of course no, you don't have to keep an administration of your hours, networks it's not necessary, no, no. Well, it was in the end. So, that took a little bit of time to get everything sorted there. There were timesheets, there was paperwork. Well it was all trial round and they learned from it as well.
So if you would now be going to that website and find the form, please fund my open source project, be prepared, you will have to keep timesheets from the beginning.
The good thing is that with the funding from STF we have achieved the three goals that we set out. So open BGPd now has ASPA support, there is already an Internet Exchange running it, so the AS path relationships are being verified on the Internet Exchange in Calgary. So that is working. And the route decision engine performance improvements are still being made and Linux kernel supports, the same issue that BIRD was just telling us about, is also being done.
So if you do have an open source project and you would like an unknown German fund to help you get that done financially, then go to that website.
What have we learned as a foundation so far? One important thing is that we are really happy with the structure of being a foundation. It is not for profit but there is this structure, this drawing that Thomas King put up in the first meeting, and that means that we, as a Board, are also like we are being helped by our supervisory Board which consisted of the members of the IXPs to make the right decisions. So, it became clear after a little while, of operating the foundation, that maybe our business model was not the best, because what happens, there are of course Internet exchanges in various sizes, large ones, smaller ones. The smaller ones can just install the software and it will work for them. For the bigger ones, I say not the case because they have the challenge of supporting so many peers and maybe a very large configuration. So, we were actually chasing a kind of client, as it were, of which there are not a lot, because only the very big Internet exchanges would need to give us money to improve open BGPd.
It turns out that supporting RPKI client, which was an easy thing to do because it is maintained by the same development team anyway, that really helps. There are also companies that need to have RPKI database in their infrastructure, and they do want to talk to us about how to set that up in a more commercial fashion, let's say.
So, even though the foundation is called the route server support foundation, the word "Support" does not necessarily mean that we will sell you a support contract. I mean we can, but it's not necessarily the case.
I find it more to start meaning that we support the development of the software. So, if there is anything that has to be done on open BGPd, we make sure it happens. That is the support that we mention.
And well software development stays on track if developers work with peace of mind. And I saw a couple of nodding heads earlier when I made my first remark. And I am also repeating what we heard before: If you use open source software in your company, then please support it. It doesn't have to be open BGPd, but please make sure that the developers can work, pay their mortgage and via their health insurance.
Any questions for me? Not too technical please, I will have to ask Job to help.
(Applause)
ONDREJ FILIP: We have a comment from Carsten Schiefner, not a question, but a comment. "Happy to see, and rightly so, the tech fund to stretch beyond the borders of the federal republic. Good to know. "
MARCOS SANZ: Thank you very much. It's time now for the lightning talks. And we have two submissions. Everybody knows that network developers are very good with graphical user interfaces so Maria is going to talk about ‑‑ could you explain that please.
MARIA MATEJKA: Who was preparing that presentation? By the way is that colour the same as my T‑shirt. Because, that colour is different than that colour.
You all saw that the GUI is a graphical user interface, did you in so, it can mean a lot of other things. Well we are not using go, we are not using UML and we are using and support IPv6. So, at least one of this is true and I must say that, for example, lots of the route servers, lots of the IXPs use go because we run a lis looking glass, so...
.
It can be a graphical user interface and you will see some image from it. Because we were forced to start thinking about support for Microsoft Windows. In fact, we were asked two times during the last seven years by some students about whether it's possible to port BIRD on to Microsoft Windows native API, and we told them, well everything is possible. Here you have some pointers to recode. Here you can start with those things and let's see, and they never asked for it again.
I remember somebody from Microsoft telling me the terminal is dead and two hours later opening a terminal so I'm saying the terminal is dead and I will open a terminal after. I sit back there.
Anyway BIRD has a so‑called machine hostile interface. It's also called a human interface, how many ‑‑ it's not even friendly for many humans. Anyway, it's really hostile for machines and I have seen lots of bad implantationings of our CLI parsers. I would say that there is probably no CLI ‑‑ parser of BIRD CLI which would be completely valid, even with ‑‑ especially considering our ongoing changes in the CLI, which is kind of a nightmare for developers because we don't document it.
So, we are trying to answer the programmers inquiries.
Please apply proper invectives on to us.
We are going to create an API based on CB OR. There are lots of requests for JSON, and I will say it here, I said it before and I will say it until people stop asking me, generating of JSON is slow. It's slow as hell even now, if you are dumping the whole routing table, 50% and more of the CPU time is spent in formatting decimal numbers because you have to divide by 10. And it's not fast.
So, we are using CB OR, we are going to use CB OR, it's a binary protocol, a binary format which has a good ‑‑ it's good in a way that we can just take our Internet data structures and with not much modification we can push it into the socket. This way we don't spend so much time formatting any number. It will be there in binary.
But first, we need to have some testing facilities. So, we are going to implement our own CLI parser, which will be right. All the others are wrong. Our CLI parser will be right. It will do the conversion between our CLI and Python object model. We are also preparing an object config package meaning that you can programmically define a config and it will dump that config into file for you and in combination with these two, of these two, you can do almost anything you want.
After that, or maybe during that development, we are going to gradually convert our CLI to that CB OR, and we are going to implement a CB OR in the Python package which will be good in the way that we can plug it into our tests and check whether it hasn't changed. The work can be done in parallel. So there would be an another slide with something more.
There is also BIRD GUI. I was playing with it during while travelling to here so it's like three days of work in train, and during the Plenaries. It uses the Python CLI to objective package because I needed something to use the package to approve that it's like a proof of concept. It's using QT and PY side 6. It resembles the way that I'm progressing in C but it's kind of object like, so well I am a C programmer, so it doesn't probably look so well for people who are used to Python. Things I learned. You can make a QT slot from a decorated object method. I spent a day debugging this thing. Python started to crash. It is not a good sign when Python starts to give you faults.
So this is call for contributions. The branch Python‑CLI includes this work. Please, it can rebase sometimes. There is a proof of concept implementation. The next month we are going to do sop collaboration with nix.cz. They are basically going to implement much of the things. If you are using BIRD and need something in the API, we won't implement the API completely in the first try, so please tell us what you want. Don't tell it now. I won't remember it. Send us an e‑mail please. And I think beginning in August '23 there is an open window for contributions in this. We will first try to make some scaffolding with nic.cz and then it's going to be open even for you.
So that's it, questions? Explanations? Discussion.
ONDREJ FILIP: Okay. We have room for a few questions. Are there any questions? I don't see any. Just looking at my colleagues, is there something in Meetecho? No. Then, thank you very much Maria.
(Applause)
ONDREJ FILIP: And ‑‑ so we have the last but not least presentation of today. So the floor is yours.
ALASTAIR STRACHAN: Hello one and all. I know I am standing between you and coffee and cake so I will try and speed this up. I did speak to a friend yesterday who has never been to a RIPE meeting when I said I am doing a lightning talk they asked is that where you just do a presentation but talk really quickly. So I'll try not to be too quick on that one.
STENOGRAPHER: I'd appreciate that.
ALASTAIR STRACHAN: I work at the RIPE NCC as one of the community development officers. One of the children or the babies that I have within that role is the Community Projects Fund. So the Community Projects Fund. The RIPE NCC has a long history of supporting innovative and fun projects and ideas across its long history. We formalise these in 2017 as the Community Projects Fund. So we have €250,000 a year to give away to projects that benefit the good of the Internet, the resilience, sustainability and operation of the Internet. Over the last 50 years we have funded over 30 projects and we currently have a call for applications that is open now. If you are working on cool things, please be sure to submit your applications. I'll go through the process shortly.
The project fund itself, we have a Selection Committee that is made up of six volunteers, five from the community and one of the Board members. So we have Aidan, Jaya, Fiona, Flavio, Maria and Sam you nay. They are the ones who do the real leg works when it comes to scoring applications, grading them and selecting the winners, there is a pretty standard ‑‑ well standard, maybe not the best word, but there is a pretty strict selection process, so the Selection Committee themselves have received all the applications that we receive. They then go through the process of scoring those, one to five on the quality of the plan, the quality of the team, the diversity of the team, including geographical diversity, the innovation, the knowledge sharing and the general interest, and also the impact of the project so once they have scored all the projects, we then basically take the top ten scoring projects from each of the Selection Committee, they go into the kind of short list, and then the Selection Committee meet once, twice, three times, however long it takes to come to agreement. And then they select those winning projects from there.
So we have a ‑‑ I apologise because the text on this is ‑‑ it's not as bad as I thought.
We normally launch the call early spring. This time we launched a little early, we launched the 1st March and the application period is open for three months. So we actually close, as I have said and I will repeat quite a lot, the application window closes the 31st May. So next Wednesday, so if you haven't submitted your cool projects yet, please do so.
The Selection Committee then has between six to eight weeks to go through those three evaluation rounds and the scoring rounds. Once that's done, it's then back to me to organise the contracts announce the winners, things along those lines and then the funding is released. We usually do the funding in a 40: 40: 20 split with required project updates before we give the next cash out.
In regards to the funding itself, funding Max is €250. The majority of the times ‑‑ I mean if there was a life‑changing project that came through that was going to revolutionise the world then potentially the Selection Committee would pick one project but a lot of times they go for more vary in the projects and slightly less funding but the maximum amount is up to €250,000.
Now, as I said Erik Romijnier there have been over 30 projects ‑‑ I'm not going to sit here and just lit a long list of projects. I have included the URL on there but there is a few here that have either presented at the RIPE meeting or you may have heard had have. There is the AI 4NetMon, the ARTEMIS project, the DE Sec that presented this week, there is FP DNS 2, and as I say there is a lot more of these projects that we fund that had you can success on the link there.
So, with that, hopefully I didn't talk too quickly but I will reiterate the call for applications is open right now and you have till 11:59 UTC on Wednesday the 31st May to submit any application that you may have. And yeah, any questions, come find me.
(Applause)
ONDREJ FILIP: Any questions? I have a question for the room because we had a discussion.
MARTIN WINTER: We had a discussion how much I would know, just by show of hands who knows at least two of the projects they have done so far? It's not as bad as I expected.
So, we had some discussion probably in the future open source meetings, have a bit more updates, so at least ‑‑ because I had personally had the feeling the results are sometimes a little bit getting lost, while there is excellent work done I would really appreciate the results.
Thanks.
(Applause)
MARTIN WINTER: Okay. Then we are coming to the final slides. We have a view organisational things. We have first an announcement from Ondrej.
ONDREJ FILIP: You know, one short announcement and there is also an important thing for some of you. We founded this Working Group ten years ago, roughly, with Martin, a long time ago, and after such a long time, I think it's a good thing to say that I would like to step down immediately after this meeting, so this is the last time you can see me on stage. There are two good reasons, one of them is those long ten years and of course another one is that I am a Chair of RIPE NCC and I would like to content straight on this important role for the community. So this is the last time here on stage with the this badge and I am saying it with bleeding hearts but, you know, of course I will be around because this as I said many times is the best Working Group during RIPE meeting. So thank you very much. And that's it as that's the announcement.
(Applause)
MARTIN WINTER: Ondrej I'd really like to thank you, I'm not sure who is around that long went started it, we started it basically at RIPE 65 was like the decision to start it and the RIPE 66 was the first Open Source Working Group. It was basically me and Ondrej we started together, to talk about the whole thing. We finally managed last fall to get one more Working Group Chair, we are really thankful. It also means that Ondrej stepping down that we would really love if this fall we can get another Working Group Chair again. So I would really appreciate some of you over the summer break think about it and see if you want to step up there and give some new views in there, new opinions and help to get this Working Group to make sure it station the best Working Group.
MARCOS SANZ: Okay, so if you want to be a candidate and if you have your interest in be a co‑chair of the Open Source Working Group, or you know of somebody who would be interested, send the nomination. The e‑mail address is the same as the mailing list. . Open source source and then Working Group‑Chairs, and we have time until the next fall. Talking about mailing lists, we have been thinking about this, what is the reason for not having that much traffic in the mailing list. It's more or less the same thing that the IoT Working Group said yesterday, it's maybe some generic identity crisis of Chairman that when they see no traffic in the mailing list they think something is going wrong. Maybe mailing list is not the right medium any more to discuss with each other. I think that afterwards at the Plenary, there will be a discussion about mailing lists. Yeah, the Community Plenary, there will be a discussion about mailing lists being an appropriate way of discussing with each other nowadays, my children don't have an e‑mail address any more.
But regardless of that, are you happy with what the Working Group is doing? How the Working Group is navigating these times? How the Chairs are steering this? Do you think that the Charter of the Working Group is still the Charter of the ‑‑ do you think that the Charter of the Working Group, as it was founded in 2013 in Dublin, is still current, up to date, or is it too broad or generic? Does it need some milestones, something more specific?
.
Thanks.
AUDIENCE SPEAKER: This is a topic super close to my heart. Look, the BIRD talk that we just listened to, it's a great talk, but it could have been in the Routing Working Group. And maybe that would have been a better fit for it. And what is a topic super close to my heart is how to actually make open source work as a community, as a collaborative project, or as an organisation like Niall has explained in his talk, how to actually make it something that is successful in an organisational manner. And I feel, over the last years, all of the talks within this Working Group have largely sort of resolved around a project that happens to be open source but is not really the open source aspect of it itself. And I think a larger focus on that, how to get other people to contribute to your project, how to make a project financially sustainable, I think those topics would be a great fit for this Working Group, because I think each and everyone of us in some way relies on open source software. But, if ever do like an app install engine x, app install inbound etc., do you think about who actually makes this, how is this funded? Is this just a hobby project or is there a large corporation behind this? And raising more awareness around this topic I think would be a super valuable addition to this particular Working Group.
MARTIN WINTER: So if I can respond to that. The way I understand is like a part of it is the whole funding model, part of it also there may be we had from the talk selection. I mean originally the idea, me and Ondrej when we started, obviously we both come from the routing side, him from BIRD me working for the after a routing before Quagga, our view was yes let's see the community to get better contact we double up from the open source and users of it and trying to make that connection and give like open source developer a chance to talk about it and make the connections with people or using who may even be able to fund it from your feedback, it sounds partially in that direction, partially with different. I would be very interested especially if you want to contact me afterwards or on the mailing list discuss that. I am very interested to like hear a bit more exactly from you.
AUDIENCE SPEAKER: Can I add. By the, I am Alex Band from NLnet Labs, just to state my affiliation. With regards to mailing lists, a couple of years ago when we start our RPKI projects, naturally I needed a discussion platform and I did two things: I set up a mailing list and I set up a discord servers and the discord server has 500 members and daily active lively conversations and the mailing list is completely dead. So, I might as well just get rid of it. So discord is really working for us. I think SLAAC also works for a lot of people. It will be interesting in the next session. ASNs stance thank you Alex. I think Neil's was first.
AUDIENCE SPEAKER: Alex thank you for what you said about the presentation. I can give a small anecdote. If everybody promises to keep it in this room, okay.
So, the developer of Curl was also in the sovereign tech fund meeting, so this is a programme that is in every OS, even in Windows. The guy said he never received a penny from anyone until the sovereign tech fund came along. This is why I went up to that stage and explained to everybody this is our foundation, this is how we do it. Please do it as well.
Second comment. I am vice chairman of NLNOG. The NLNOG mailing list is dead. We have discord server in the Board, please keep that a secret as well. We have invited some people to help us test. It has seen more messages now than thereof ever been on the mailing list in total.
MARTIN WINTER: Thank you. So we have definitely bring up the topic on discord or something similar.
AUDIENCE SPEAKER: Maria, BIRD. I am just reiterating of the thought whether these routing server talks belong here or to the routing group. And I must admit that I am submitting these talks here just because it's kind of tradition, and if it was properly stated that this is not about specific open source projects but about the open source community and what are the more common and generic persistence, then I would say okay, let's go to the Routing Working Group. And I think it would be completely okay and maybe better.
Reiterating Ondrej, I also thought about saying something about how the CRA is going to fall on us, but I didn't manage to prepare the presentation properly, so maybe it's a topic for another meeting.
MARCOS SANZ: Okay. Thank you Maria. Then with that, we are done. We are here to serve you, contact us afterwards if you have some comment, if you want something from us, and ‑‑
MARTIN WINTER: There is a reminder there will be new elections for Working Group Chairs or if you have a strong opinion, we would very much welcome you to join us.
ONDREJ FILIP: We should say some final thank yous. We need to thank the scribe who was Michelle. I have a special thanks for all stenographers, because I grew up with language that articles are options, so whenever I do a do a lot of small mistakes in the English. When I read the text later on it looks like English. So thank you very much for that.
STENOGRAPHER: You're welcome. I just put up what I think you're saying.
ONDREJ FILIP: Personally from me I am looking forward to sit in the back stage for the future meetings. Thank you very much. And the meeting is over. Thank you.
(Applause)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
