Wednesday, 28th October 2026. Side room. 9am. OpenSource.
MARCO SANZ: Good morning everybody.
Welcome to the OpenSource working group. If you are looking for the networking group, they got the bigger room this morning. I am so happy to see you all here, that way you.ll just confirm you like OpenSource a lot, you are willing to stand up and wake up at and get here at 9am in the morning. We'll see if we can make the slot later in the afternoon for the next RIPE meeting. For the time being, so so cool that you are here.
Let's take a look at what we have planned for today, first of all, welcome, thank you to the RIPE scribe, thank you very much to stenography services and we'll be monitoring Meetecho, somebody has a question or a comment, we'll be checking Meetecho and this session is being live streamed, please be aware of our Code of Conduct, you can read it in the first QR code, the Code of Conduct if you feel the behaviour of some person is not appropriate and you feel discomfortable with that, we have a Code of Conduct team you can approach them in that matter.
Please remember to rate the talks. It's so important that you rate the talks. You log in, just click and give a score of two or five, that's very helpful for us chairs to know what you think about our own work of selecting the talks.
Then we send the minutes of the last RIPE meeting to the list. We didn't get any comments to the minutes so unless someone now rushes and goes to the mic and wants to say something about ‑‑ no, then the minutes are approved. And yeah, we'll be about to finalise the agenda in a moment, we still have one more matter, very important one, namely Sasha's term as a co‑chair was finalising at this RIPE meeting. We sent a call for candidates to the mailing list and the call for candidates stayed open for three weeks and we got one volunteer, that was Sasha, she was willing to run for another term, something we are very happy. There were no other people stepping up to become chair, so she was the only candidate to announce this to the list and we got no feedback at all. Which I understand we are all very busy and we have many things to do and we like Sasha a lot, but I would be very, very grateful if at least one person, one, would step up, go to the mic and say, yeah, I support Sasha's candidacy because then I could happily say, yes, she got the majority of the, of expressions of support. So
Supporting Sasha running for yeah, OK, I see some hands going up, that's very nice of you. Thank you very much.
So then that being said, I would say congratulations, Sasha for candidating, and I see there is yet another person going to the mic. Thank you.
NIALL O'REILLY: It's a procedural point.
MARCO SANZ: Who are you? It's a procedural point! (APPLAUSE.)
NIALL O'REILLY: That was next on my list before I came to the procedural point. I am Niall O'Reilly I have been around for a while, I made all the mistakes possible as a working group chair and the one I want to point out today, it's not about majority, this should be at least one expression of support, of course. But we shouldn't be doing majorities, we should be doing consensuses, and it's sometimes subtle to make the distinction. But Sasha is great, I am adding my voice of support since I have the mic and when we get to item 6, I will want to be, I want it to be known I have already made a secret deal with the other co‑chair, but let's bring it out in the open for transparency, I need a little time at item which is traditionally Z, any other business, thank you.
MARCO SANZ: Thank you very much and thank you for the expression of support. So congratulations, Sasha. Sasha is not here with us today, she's participating remotely, but she's hearing this so you did a great job.
(APPLAUSE.)
There you have the oaf view of the current co‑chairs and the end of terms.
Anna is also present representing the RIPE chair team she can confirm she ‑‑ we followed through process, thank you, Ann. Now let's go to the OpenSource part now, so we have three great talks, we have selected for you.
And we already heard that under any other business, Niall wants to say something. So then let me greet Barry, Barry is going to talk about his CRM, I am really looking forward to this.
BARRY O'DONOVAN: Good morning, great to see you all here. For what, is I guess, a regulatory presentation, which I think reflects the world we are all living in that as Open Source developers we are caught in these things as well. I am going to talk about the Cyber Resilience Act. And if you are of a mind, can you please let me know if you have heard of the CRA? Great, most of you, all much you nearly. Have you looked at the CRA in relation to OpenSource software and do you like what you found?
Yeah. OK. So to set the stage, we are in a regulatory tsunami. Everybody in this room probably knows most of these acronyms stand for, Tina the stenographer, probably knows what they stand for. We are, if you are an operator, you are caught by NIS2. If you are in the financial sector, god help you, you are caught by Dora. We at the EU AI act and then the Cyber Resilience Act. There is in sort of the wider political spectrum, there is a lot of push back in terms of the volume of legislation that's coming from the EU. Emanuel Macron called for regulatory pause, that was in relation to environment al legislation but I think it applies to all legislation, if you are want a scare at bed time look at Mario Draghi's competitiveness report but which found in our industry alone, there's over one hundred tech related laws and they have spawned 270 regulatory bodies. That's roughly 10 per country each.
So it is affecting competitiveness.
Ireland is by no means different to anybody else, we are currently hosting the EU approximates, and our government worried about being embarrassed by our lack of transposing laws gave our civil servants a spank at the start of the year. It didn't achieve much, we still haven't transposed NIS2 for example, we are still acting as if NIS2 is law in Ireland, wove all of the framework, the NCSE is doing the right things but it's not actually law yet and probably won't be until next year sometime.
So, when I first proposed this presentation, I put it very much in the context of NIS2 and the CRA and the chairs quite rightly said to me that not everybody in the room is an operator, concentrate on the CRA, I want to give it a little bit of context on NIS2 and the CRA.
So if you are an operator, NIS2 applies to you in the sense that it creates a legal obligation to manage cyber risk and supply chain vulnerabilities. And the question then is what about the software manufacturers and the OpenSource project that supply us. And that's where the CRA steps in. The CRA is a piece of legislation that's 90 pages long, the EU's guidance on it published last July is another 90 pages, so there's quite voluminous in terms of text, and it applies to products with digital elements, so essentially anything you can plug in that might run firmer, it applies to stand alone software, it applies to 50 euro CPEs and 50,000 dollar routers. I was talking to some manufactures of routers and they are banging their heads against the wall with some part of this because some of the way, some of the standards coming out call for example for automatic updates to be enabled by default and nobody wants that router doing an update at 3pm in the working day. It applies to all of those including perhaps your digital alarm clock. In summary for you, NIS2 governs how we run our networks and the CRA governs the software we run it with.
This talk is very much going to be about OpenSource software under the CRA, that massive act and all of that text largely applies to commercial manufactures, and when the CRA was first envisaged, considering the broad spectrum of devices and products and services it applies to, OpenSource software was somewhat overlooked and the initial draft version of the CRA would have ended OpenSource software in Europe, it would have put us in the same basket as commercial manufactures, subject to the same massive legislative fines and subject to EU marketing and huge amounts of bureaucracy, a lot of the OpenSource foundations and developers educated the Commission on what OpenSource was and a lot of it was explaining this that we are all used to, updated from last week.
I don't know if many of you know Ondrej Sury. Ondrej, I don't know how or why but he somehow fell into a place he now supports many versions of PHP for many versionings of Ubon and Debian, he was very busy last week and Ondrej was quite literally a critical piece of quite a lot of digital infrastructure last week and it was explaining to the EU this is where OpenSource developers exist, a lot of individuals, a lot of volunteers but creating critical software in digital infrastructure.
Look at the developer of curl, he talks about the CRA and its effect on him.
So where has the CRA come out in terms of OpenSource software developers, the first piece of good news is individual OpenSource developers are not in scope, unless they are working in a commercial activity, unless you are trying to make money from your OpenSource software, you are not in scope. And the CRA goes further to state some things explicitly, just because you put OpenSource source in Github or release packages through packages or MP N, that does not mean that you are making software available on the commercial market.
So that stuff is excluded.
Then it goes on to say that while you must look at everything in the round, various activities do not automatically put you in CRA scope. So accepting voluntary donations, that might cover the cost, including reasonable personal expensed an living expenses that doesn't put you necessarily in scope, maintaining a project on Github, making releases, accepting PRs, isn't going to put you in scope.
Receiving bug fixes or pull requests from engineers employed by commercial corporations doesn't put you in scope and doesn't them put in scope. And then receiving sponsorship and non‑commercial public grants and academic funding doesn't put you in scope either.
So there's a gap between individual OpenSource developers and manufactures and that's where the EU created this new entity called OpenSource software stewards, so this is for legal persons, which in EU language is not individuals, individual is an international person, a legal person is some kind of company or entity. So individuals cannot be OpenSource software stewards. So an OpenSource software steward is a legal person other than a manufacturer and that is to say that if you tick the boxes for being a manufacturer, you can't side step your way in and pretend you are a steward; if you are a manufacturer, you are a manufacturer.
And it's where these stewards have the purpose of systemically providing support for the development of OpenSource project. Intended for commercial activities ‑‑ that's kind of a key thing we'll come back to and ensures the viability of those products.
We'll just look at the table first. Again we are dealing explicitly with OpenSource software here, right. So it's, what is a steward versus what will trip you being into a manufacturer of OpenSource software, so what will actually get you trapped in a CRA.
Typically stewards will be foundations or associations that don't monetise the software; whereas a manufacturer is going to be anyone who tried to make money off it, including an individual.
The monetisation model in terms of stewards is what we all know as proper OpenSource software, the code is freely available, it's distributed without charging any money, there's no pay wall tiers. Whereas the OpenSource manufacturer is where you start to try and monetise that OpenSource software.
So you might have ‑‑ the typical way of doing it is you have an OpenSource product you give away for free and you have a commercial version of it that has extra features, well that's going to make you an OpenSource manufacturer because you are monetising that. And in fact you are going to be both things, you are going to be a steward for the OpenSource version and a manufacturer for the commercial version.
And it's not that these labels apply to the organisation, it's on a product by product basis so NL Labs is a good example, they have published good material on the CRA and they have looked at the kind of things that they do for example routinator and they have decided that falls into the OpenSource software steward bucket and they have declared themselves an OpenSource steward for some of those products. And for other products that they publish, they have said we are out of scope for those. They don't meet the definition of OpenSource software steward, it's a product by product basis.
Intended for commercial activities is a hard one to unravel. But in the CRA, there is the recital which is all of the sort of definitions and explanations and this is what we are doing, this is why we are trying to do it and there's the act which is sort of the legal structure of it. And in the recitals, it says "ultimately intended for commercial activities," that means in direct use as well. So if you take IXP manager, INEX is not for profit and it's used by other exchanges not for profit, but just because we are not for profit doesn't mean it's not a commercial activity; we are charging for ports. Even if it's not for profit, it's still a commercial activity so the purpose of making money does not, is not a requirement for commercial activity in this context.
The Commission in the guidance, they have published, they have a big session of OpenSource swears which is an easy read compared to the act and they have given lots of examples, I have got a link at the end rather than going through it here.
Let's talk about some time lines. The CRA unlike NIS2 which is a directive, Ireland hasn't transposed NIS2 into legislation yet, so NIS2 isn't law in Ireland but unlike NIS2, the CRA is a regulation, it's like the GDPR, it comes into effect as soon as the EU Parliament enacts it, CRA applies EU wide and doesn't require national bodies to do anything.
The first important date for the CRA happened last month, which is mandatory reporting for manufactures. It doesn't apply to OpenSource software stewards, there was a bit of confusion about that but the an niece is a, the European EU cyber security agency, has made it clear it's not for OpenSource software stewards yet.
Mandatory reporting is two categories of things that manufactures have to report to an niece is an and to their national C cert, cyber security incident response team.
And they have to do that within certain time lines and so facilitate that, it needs to have have created a platform which went live last month, you can register our OpenSource project on it but they are not accepting reporting from OpenSource software stewards until next December.
And that's December 21st next when when everything else comes into effect if you are a manufacturer and that's not really in the scope of this presentation.
I did say there are fines up to 15 million or two and a half per cent of total worldwide annual turnover, so if you are a manufacturer there's a lot of teeth in the CRA.
What do you need to report. From December next year you are going to need to report any actively exploited vulnerability. That is not just a vulnerability, but one that's being actively exploited, and the clock starts when you become aware of that. Sometimes that's obvious. Maybe it's in the media that there's, some piece of software is being actively exploited, sometime it's not so obvious, you might get a report from someone who says, look, I think you have got this vulnerability and I think it is being exploited in which case you have to act as far as to confirm it and once you confirm it, your clock starts. You should also inform all users, that's where appropriate. If informing all users is going to create a greater security situation, you don't have to do that immediately.
You also have to report any severe incident having an; impact on the security of the product; that's, for example, if your GitLab or Github accounts get compromised and you can't stand over the security of the product you released.
One of the gotchas here is reporting obligations continue to apply after a version is no longer supported by you, there's a long tail in this. In terms of time lines, once you become aware these things have happened, you have 24 hours to do the early warning report to the national CSIRT and enenniece is a, it's very easy to register for it but you have to have an EU log in, which is a separate thing and it takes a little bit more effort to get that, you can do it all online. Within 72 hours, you have to give a lot more detailing what's going on and in a longer period, you have to give a final report.
And this is to allow these incident response teams to inform say your product is used in the energy industry and it's to allow the energy regulators to inform the energy companies that this is a serious problem and that they need to address it.
Other obligations of OpenSource software stewards is establish a cyber security policy to foster the development of a secure product as well as an effective handling of vulnerabilities. There's a few things that should cover, it should cover secure development practices, vulnerability intake, how people report to you and the remediation of discovered flaws, it should be tailored to your organisational set up, if you are a very small steward, it should be very much tailored to your resources and that is provided for in the act.
And it should promote the sharing of information concerning discovered vulnerabilities within the OpenSource community.
Then the only other obligations, you must cooperate with the market surveillance authorities at their request and that really means they might ask to see your policy and you must provide it. Or if you don't have it, they can say you must create it.
But then the question is where's the stick: So these are things you should do as an OpenSource software steward, what will they do to you if you don't do these things. The reality is not very much. I think that's why hands stayed up when I asked if they were reasonably happy with what's come out in terms of OpenSource in the CRA. There's no fines or any monetary penalties for any instringments and the act goes further to say that member states should not impose other kinds of penalties with a monetary value, it's about persuasion rather than punishment, so how will it affect you if your publishing OpenSource software, well if anyone is covered by NIS2, they are going to be asking you questions if they decide that your software is essential or critical in their supply chain, they might asked to your security policy or develop policy.
Manufactures who have a lot more obligations under the CRA have to do due diligence on the OpenSource software they use in their products and this is what the current developer talks about a lot, these manufacturers contacting him for certain bits of information.
So you have ‑‑ people will come to you in these respects if your software is important enough to them.
It's also going to be about your reputation.
If it becomes public you are not doing these simple things, that's going to affect your reputation. And you know what they say: It takes years to build a reputation and seconds to lose it.
The other thing which might be quite embarrassing, you are if you are not getting this information out or you are not informing your users of vulnerabilities, CSIRT can go over your head and do that directly which is going to look very bad for you.
So consuming OpenSource under NIS2, I am going to briefly touch on this which is just to say that article 21 of NIS2 is where a lot of this stuff sits.
And in NIS2, the broad effect for anyone who is covered by it means that we had to go off and get ISO 27001 certified or cyber fundamentals or something else and that meant that we had to do these supply chain vulnerability checks and supply chain management and document our usage of OpenSource software and figure out where vulnerabilities are published and thing loo like that. It's free software is no longer excuse or unmanaged supply chain risk.
What should operators do, you should have a software asset inventory, you should be tracking vulnerabilities and you should have a vulnerability management policy that talks about timely patch management.
In terms of IXP manager, INEX has looked at this and we do fit the category of OpenSource software steward. What have we done to align IXP manager to the CRA: We have published a secure application development policy. In fact we did this before the CRA because other exchanges that were using our software were doing their own supply chain risk management and asked us for these policies. So you can see how this stuff kind of feeds in just because of NIS2. And we have a formal responsible vulnerability disclosure policy, we can take in vulnerability or you know bug reports or security issues through a number of different channels and invariably everybody seems to be using Github's version of that now. And I think like anyone else in the room, over the last six to eight months, we have been dealing with a huge increase in vulnerability reports all through the use of AI or AI assisted security researchers, and in fact, I think the last five or six releases of IXP manager have been mostly around security patches and a lot of this has led to pro active code hardening, when we get these things, we learn from them and we are able to look at the wider IXP manager code base and figure out what else might be an issue.
And we haven't done it yet because it's not ‑‑ we don't need it until next December of 2027, but a CRA escalation playbook, which is essentially when we get find out or if we find out a vulnerability is being actively exploited, that we have a playbook for reporting that on the single reporting platform.
If you are publishing software as an organisation the kind of three scenarios you fit into is out of scope, if it's just simple script, simple code dumps, BGP filter generators, stuff you are not actively maintaining, just stuff you want to share.
If you are doing this sustained infrastructure tooling, that's going to put you in the steward bucket.
And then if you are monetising it, you are going to be in the manufacturer bucket and that's the very awkward bucket to be in because that brings a huge amount ‑‑ besides just the fines, there's CE marking which means you have to assess your code against different vertical standards, conform the assessments, SS bomb requirements and so you have a lot of work to do there.
In terms of resources if you download the PDF, click on these a, link to the Cyber Resilience Act, a link to the NIS2 article I referenced, the Anesa who have created the singular reporting platform have published some frequently asked questions and it's in those where they have clarified that mandatory reporting for stewards doesn't begin until December next year so they have said in those FAQs they are not accepting reporting from stewards until December next year.
You can see IXP manager secure application development policy which is creative comments attribution and share alike so you can use that as a template if you don't have one, and similarly for our security policy, you can use that as a template, security policy is very much bread and butter.
The image on the right is not meant to be legible by you, that's in the Commission's guidance, so in their whole session OpenSource software, they have this flow chart that helps you identify are you out of scope, are you a steward or are you a manufacturer.
So, thank you for your attention. And if you have any questions, happy to take them.
(APPLAUSE.)
AUDIENCE SPEAKER: Alistair Woodman. As somebody who has been involved in reading CRA legal stuff and one of the first organisations that wrote back to the European Commission about what we didn't like in the start, I think ‑‑ I am not sure what you think about things at the moment, but yesterday I said very clearly that I think that AI is overtaking what this regulation is, we shouldn't be sitting in this room being happy about the fact that dates are pushed out, we should be actually complaining that we can't be communicating about issues to any of the European bodies and the regulatory stuff. This stuff is getting serious. It's going to get very fast in the next 12 months. And I think just sitting there and assuming we are going to be OK for 12 months because some date hasn't turned up yet is not a good idea. We should be actively communicating that this stuff needs to be good. And we, as people who are still going to stay in the OpenSource area, have to meet and exceed these dates and time lines. We saw what happened last week with PHP; it's going to be happening all over the place, we can't say we are immune. So some people will want to get off this bus. But if you are staying on the bus, you better get ready for the fact that it's accelerating and it continues to accelerate. We need to get good with our tooling. And manufactures are way behind, right. I don't think we are the problem in this room, the folks who are attending this thing. We have good tooling, we need to make it better. Our consumers are the ones that I am worried about.
BARRY O'DONOVAN: I agreement completely on that; it wasn't just PHP last week, we saw over node, UEFI have some problems, it does keep coming and we hired a new developer eight months ago and that poor man's life has been in taking in vulnerability reports from AI assisted security researchers, so it's, it's a tonne tonne of this stuff as well at the moment.
AUDIENCE SPEAKER: Eric. We are manufacturers, it hit us very hard we did a lot of those stuff and we are in the process to be fully compliant with the CRA. You say you have to report it at local CSIRT and Anesa and as far as I know, it's only at the CSIRT, where is the difference?
BARRY O'DONOVAN: It is Anesa and the CSIRT but there is a single reporting platform. So it's one place that covers both.
AUDIENCE SPEAKER: OK, when you report that the CSIRT is automatically registered at Anesa.
BARRY O'DONOVAN: When you register on an Nessa, you pick your CSIRT, I would say the NCSE in Ireland, if I make a report, it goes to Anesa and the CSIRT through that platform.
AUDIENCE SPEAKER: Thank you for the clarification.
MARCO SANZ: Any questions from Meetecho? One last one from Maria.
MARIA MATEJKA: Just a quick one. I am kind of afraid that the question, whether somebody is a steward or the manufacturer is going to boil down to the question before some court because until then, I am expecting that nobody from the appropriate bodies would be OK with saying yes you are a steward, yes you are a manufacturer and this is something like bringing so much inconsistencies to the market. Did you look into it.
BARRY O'DONOVAN: I think in some cases it's going to be black and white if you are a steward or a manufacturer, but there's going to be a big grey area in the middle and I think a lot of case law is going to come to make that determination.
AUDIENCE SPEAKER: I would second that observation as well. My reading of the legal stuff is that in principle it's very clear whether you are a manufacturer or not and that will be decided by courts. If you don't fall into that bucket, then you can say you don't want to be a steward and you can be told you are acting as a steward and then you would change your behaviour. So I think that's a mixture between regulatory and legal and whatever it is and I think you can either see it as a badge of honour or you can just see it as they are going to label you as, you node, agent provocateur, or something like that and that's fine too, I don't mind, right. I mean ‑‑ because to your point there doesn't seem to be any legal consequences so it doesn't matter whether you are flipping between quantum state of contributor or steward, your reputations will oscillate and you have to worry about the barriers of being a manufacturer or not.
BARRY O'DONOVAN: Exactly.
MARCO SANZ: Thank you for another excellent presentation, (APPLAUSE.)
Our next presenter is a new one to the RIPE community, please welcome him with a very warm applause, Bruno Banelli and he is just starting right ahead with a very interesting presentation he made BIRD ran on a very usual platform.
BRUNO BANELLI: Greetings everyone, thank you for coming in such large numbers. Thank you for the introduction, I really appreciate it. My name is Bruin know ban Ellie, I come from Croatia and we are happy that we finally have an OpenSource which on the market which I am going to guide you through this presentation including how we ported BIRD on it but before that let me give a short introduction, please put your eggs in their baskets before you start throwing them.
I am also a router for etc see 304267 which is a harmonising... which is directly attached to our dear colleagues Barry's previous presentation so it's one of the harmonised standards that tackles classified products. So I am happy to say that this little conundrum that you said about automatic updates is finally being taken care of and I think that everybody will be happy about it.
Regard mc of that, as I said let me start from the end. So on our little switch, we got the software working, it's been fully functional, it handles both IPv6 and IP V7 off‑load, unfortunately at this point in time it's still based on our own kernel, we are wait ing for the patches to actually be applied in the mainline but this will all come into place when you will actually see what I'm talking about. The important part is that on the switch and on the next slide you will see what the switch actually is, basically follows the standards Linux path that we would all expect and be extremely happy most of the softwares would do it like that.
So it goes from BIRD to Linux FIB, then through note fires, LAN969x drivers which is the Asic that runs our switch and the important thing and we are so happy and proud of it, there is no side, there is no FBM and no vendor agent in between for any intent or purpose of routing itself. Now the question is what does this switch, OK. So four years ago I was walking home and my partner called me an approximately, it was more than 10pm and I said yeah, what's up and he said you know what, we need to make an OpenSource switch, that's enough, we really need to put something on the market that will allow both us and all of our potential clients to enjoy what the OpenSource is, but we went and pushed a little bit more. So having OpenSource and following the mainline doctrine especially the one from the Linux kernel is unfortunately not always the same and not always the easy task. However, we were lucky enough that at that point in time micr chip decided to basically uncover most of the internals of its LAN969x Asic and of its Sparx 5 basic which allowed us to take their kernel and help both them and us in upstreaming effort to the kernel, this goes up to the layer 3 support, some of the features are being main lined as we speak. And I am repeating myself, I am just moving the date each and every time, hopefully maybe by the end of the second quarter of next year full layer 3 support will be in mainline. I said the same thing last year, so it's good that we have so many years upcoming.
But in any case, this is moving forward and this is working well. The switch itself has an aggregated non‑blocking throughput of 106 gigabits and in this particular switch on this particular switch that we have we have 24 one gig and four times 10 gig, we are now of course exploring 2.5 gig options as well but due to the chip shortage and everything else, this will all go in due time.
So, what did we actually do. It was a relatively simple, test of course, and let's call this proof of concept.
This has not been battlefield tests, but it was tested enough to that we can say with very high certainty that it would probably work pretty well in hard deployment. So you have a little disposition how this thing was actually set up here.
So the two VLANs are isolated from each other, traffic has to be routed by the switch. Making sure the packages are truly going back and forth but the Asic itself.
And VLAN aware bridge with routed VLANs was how it was actually achieved and several few slides, I will just bug you with some technical stuff, I hope this will not be too boring but presentation will be available anyway so you will be able to see it for yourself.
So we added the switch ports to the bridge as access ports, made the bridge itself a member of each respective VLAN and then put the router addresses on the VLAN interfaces, not on the ports themselves.
Finally, we set the bridge Mac after the ports have joined to make sure we really have traffic flowing through the chip itself.
There is a really small BIRD policy for this particular example and this is why I actually enjoyed seeing it work because setting it up this easily, it really is valuable and it lowers the complexity of the whole deployment. So we explicitly stated import and export filters on every BGP channel and only the test prefixes reach the kernel's main table. And finally default and management routes never enter the BGP.
Naturally, you will see in the following few slides that not everything came out of the box. So some of the things required additional configuration and additional set up.
So, we did several checks and each one of them confirmed everything we had hoped for. So we confirmed that sessions and BIRD's router choices are correct. That the Kernel installation and driver flags were properly set. Next‑hop MAC and neighbour states are correct. And of course we continuously monitor the delivery, TTL, decrements and Mac rewrites. And finally checked the CPU usage, this is the A53 core that integrated in the Asic itself, just to see if the utilisation is rising or it is kept steadily as we would expect from a fully hardware routing platform.
And after several iterations just to make sure that we are not victims of a happy statistic error, it seems that all tests have passed, so dual stack eBGP, four sessions up, routes in the FIBs, flagged as off‑loaded.
Forwarding being properly done for both IPv6 and IPv4, in both directions, import policy where a default route from a peer is rejected.
VLAN separation, which has been confirmed by setting up the bridges.
ARP and ND resolving and after the cache is cleared on either side.
And route batch of 256 extra routes added and withdrawn cleanly.
A little bit of metrics which is something we always appreciate. Talk is cheap but integers and floats are very specific. It takes less than half of a second from a peer withdrawing or announcing a route to the the change in the Linux FIB.
And second two numbers or figures are the measurements of routes gone after the peer's port went admin‑down and sessions being back after admin‑up.
Depending from which world you are coming, these figures could be super great or you could be heavily disappointed in them, regardless as I said OK, fine, this is not a hyper scaler ISP 1.6 terabit switch. So this is a top‑of‑the‑shelf switch, this is a camper switch, I like to call it a floor switch. So for those intents and purposes, and this is something that CRA teaches you as well you know, intended and foreseeable purpose of usage, off product which digital element so our intended usage exactly that so these numbers are relatively OK, I think that for that particular purpose we could agree on that.
And of course several notes here that the peer's network interface card kept their optical links up when admin‑down so the switch saw no link loss and the routes left when the 9 second hold timer expired.
Fast recovery comes from specific configuration and no BFD, no redundant paths or cable pulling has been conducted during those tests.
Now about the details of configuration that had to be conducted in order for this port to properly work. And it's really nothing special and this one in particular is not a BIRD problem and there is no patch needed. This is merely a configuration statement that you need to turn the option on and the driver check could be relaxed too. So this is nothing very specific but yet still worth mentioning.
Of course IPv6, and as we always have that mystery when using IPv6 one way or another so the neighbour discovery needs help because a few minutes after start up, a peer has to look the switch up again and can no longer resolve the IPv6 addresses. And we just renewed the switch's neighbourhood discovery multicast entries every 60 seconds in each routed VLAN. Let's call it a cheap but a hackie workaround.
Unfortunately, this is something that needs to be taken care of on the driver level so it has been reported, stated and we hope that either we or some of the other colleagues will take care of it any time soon.
Now again a little bit more statistics, just to make sure that we really were on the hardware path. Just some metrics for both IPv6 and IPv4 transit all 300 packages were both sent and received with a proper TTL while the switch was left empty handed.
The other way around, so V4 and V6 to the switch itself as you would expect in the counters, zero received and the CPU got all three hundred of them.
And a little bit more about data path behaviour. So as you can see from the table here, usually Linux would of course drop these packages, but the Asic forwards them anyway so it's really good to check the hardware path before regular lying on a system CDL to block traffic, I would presume most of you in the room are very well aware of that fact.
And of course the final metrics, we were happy to witness ourselves is the fact that the throughput actually matches the packets. You are probably aware that the CPU that's helping this Asic to run Linux and have drivers being stated is merely a vehicle to get an operating system up and to touch the exact registers based on how the drivers have been written. So pushing 10 gigabit through it would be simply impossible to achieve at all or let alone not to hammer the CPU for, you know, using it as a water warmer if your coffee machine is broken that day. So this has actually proven to be correct since you can see the throughputs on the screen while the CPU was not busier than 10%, take into consideration that the CPU is also handling the SSH session and I probably ported some additional packages. Two years ago I was playing Doom on that switch, people really liked it, I don't really remember what I left in that but in any case what we can be pretty confident is that the Asic itself was handling the packages, not the CPU which is clearly shown here.
This is the third time and there is more of the presentation. I can show you, it's going green, I like what you did there, whoever did that, I saw you two guys in the back, yeah, this is OK, yeah. Do it for the new guy, this is always fun of course! Why didn't you do that on Brian? It's just not fair. I am not mad, just stating the obvious.
So there's some limitations as well, of course, as you could expect them.
So the other routing tables have been installed but have never been off leaded. ECMP where we just set the flag but didn't actually test the traffic split. The Next‑hop objects have not been off‑loaded and FRR uses them by default and as for L3 forwarding, IPv6 and IPv4 and both on SFP ports, confirmed by captures, this of course needs to be tested on the ports that are having identified themselves and we are especially interested to see how this will reflect on 2.5 gigabit configurations which is the latest hardware design we are actually trying to push so this will definitely be interesting.
And what has not been tested are full tables and as I said, all ports so we didn't touch the copper in this test.
ACLs, BFD and cable pulls. So protocols support, route installation and hardware forwarding are three of course separate questions.
OK. So for the last slide because following up this one, you have some references and links which I will not bug you with.
I wanted to say thank you for accepting the talk. I am really happy that it's getting crowded here. I expected nothing less as I said.
OpenSource hardware supporting full OpenSource and the networks domain is getting hard to come by, even the project that are sometimes claiming being OpenSource are still using binary blocks or using mental gymnastics in order to try to prove that they are OpenSource while they are really not. So the question is do you have any questions for me that I could possibly answer to you ad hoc? Or if you want to park them and just send an email or however is better. What I also wanted to tell you, there is a Github repo, maybe it's even ‑‑ maybe it's even somewhere here, yeah, it is. It's a little bit tiny, but you will be able to see it. But it's easy GitHub.com slash Novarq. Don't ask me what it means, it means absolutely nothing, my partner had a dream and the Commercial Court in Zagreb decided to accept that name which was a happy coincidence, OK, be that as it may, everything is available on Github, including the instructions in how to build and run BIRD on the device itself, so I am waiting for any questions.
(APPLAUSE.)
MARCO SANZ: Thank you.
Yes, there is some time for questions.
AUDIENCE SPEAKER: David. I have a few questions.
'BRUNO BANELLI: Please be easy, I am going to cry and run away.
AUDIENCE SPEAKER: What is the state of support for IPv4 with IPv6 next hops. ‑‑ what is the state of the support for IPv4 routes with IPv6 next hops in the driver?
BRUNO BANELLI: I can't tell you by heart, but I will remember it and I will check with my shy engineers to get back with that answer to that question.
AUDIENCE SPEAKER: OK. What is, how is the CPU trapping for PPU packets implemented, that working currently on the driver?
BRUNO BANELLI: I think it is. This is something we inherited from microchip, from their BIRD support package, it's all right implemented, we are just working on some mainline features for the Kernel just to port them from the driver and make some enhancements because you could expect that maintainers are not happy with third party code being just pushed like that.
AUDIENCE SPEAKER: OK. Thanks. And I have two remarks, the first one is routing is a configure option, to not use Next‑hop routes in the data plane, I don't know if you tested that option.
BRUNO BANELLI: No, but I would be happy to get your issue on Github.
AUDIENCE SPEAKER: In our infrastructure we have been using Menonog switches with FRR routing on them and they also work out of the box with a special driver so that might also be an option for people to look into, they can be quite cheap on eBay as well.
BRUNO BANELLI: Sure, exactly, I am aware of that but you know, this is, this is not a question are we, has the European Union forced us to buy old switches and recycle or can we push something new on the market.
AUDIENCE SPEAKER: Yes and maybe also a question for all the people in the audience, is this... available.
BRUNO BANELLI: Yes, it is available, we only have a web shop, it can be purchased online or you can get in touch for an additional quote or co‑operation.
AUDIENCE SPEAKER: Ondrej Philip, former BIRD developer. I have a question about forwarding speed, you hoe it has one speed for one IXP, the Asic has limited... what if the amount of routes grows above that, I guess the forerunning is run by CPU, if you measure that speed.
BRUNO BANELLI: Unfortunately not because the switch is configured in a hardware way that in this configuration it should never block. But your question is spot‑on and when we will be conducting the tests with 2.5 gigabit files, we should be getting close to that limit and then we have to see exactly what you asked, so does it overflow where and how does it reflect the CPU itself but at this point in time the throughput of the Asic itself should be completely enough to satisfy the demands of the current port configuration of the switch.
AUDIENCE SPEAKER: I understand that. The particular couple is limited, if you have a layer 3, let's say, router more than switches entries, then the particular up is capable to carry I guess then the forwarding is done by CPU, how fast is the CPU in that case?
BRUNO BANELLI: We have to see. We haven't tested it really as I said, this is a proof of concept but this is a really good question and this probably is something to be explored in the further tests because it makes sense, at least to get an answer how can it, how the CPU can handle it. From what is inside, I wouldn't be too optimistic.
AUDIENCE SPEAKER: I saw the specs of the chip, I wasn't sure in your case, what is the limit for the IPv4 and IPv6 routing table, how many entries are you able to get into the Tcam.
BRUNO BANELLI: It's not data, I don't know by heart, the inches is disclosed in the microchip, they are aware of these limits. By the way I think this question is answered on the configuration part of the GitHub.
MARCO SANZ: Thank you very much. (APPLAUSE.)
And our last presentation from Victoria and Tomek, please come on stage, thank you, tell a story of what happened when suddenly one of the lab you are using decides to go commercial.
VICTORIA RISK: Thanks thanks, this working group, there's such a variety of talks, so this is nothing like the last two talks, I am the product manager at ISC and my colleague Tomek is the director of DHCP Development and when I proposed this talk, it seems like a long time ago, we had just discovered that one of the major dependencies that we were using was ending their OpenSource project and turning it into a commercial project and I thought, well, this is probably something that happens to other OpenSource project too so maybe we should propose a talk to tell you all how it went.
So this is the reason I thought it might be relevant to other OpenSource project obviously autonomous of our software uses other software, you know, we are dependent on the languages, the Linux operating system, other libraries. But this is kind of a different product for ISC, you probably know we maintain the BIND DNS server and these are traditional CLI only Linux applications. This is a new kind of a thing, so Stork is relatively new project from ISC, it's a graphical management utility for managing for DNS and D HDPservices, the really our first kind of adventure in the web‑based ecosystem. And we have a major dependency on ‑‑ or we had a major dependency on the prime NG user interface library.
And so this is a library that supports some sort of higher order functions like paginating through lots of data, or sorting tables by the column headings.
So just for an example, this is a screenshot from Stork and we are looking at your DHCP configuration and it list the subnets through different servers and some people have a lot of subnets. I don't know what's the most we have seen, but you know, definitely hundreds, maybe thousands, so this could be a very long...
TOMEK MRUGALSKI: 7,000.
VICTORIA RISK: This could be a really long table, so where you see the little green highlights, these are the tiny little up and down arrows that if you click on them, it will sort the table by that column. This is a feature that as a user I really love, something I specifically ask for and this is just an example of this is one of the features that we got by using this PrimeNG library.
One of our engineers went, I don't even remember why but was looking at the website for PrimeTek, the company that produces library in July and he saw that they had posted at the end of June a blog post entitled the next chapter of PrimeTek, there's the URL there and this was kind of a bombshell for us.
And in their blog, they explained that even though they had been producing OpenSource tools for a long time, they had an open core model where the core was OpenSource but they monetised some templates, some UI kits, and that model which had been working for them for years was no longer sustaining them.
And I am sure this was a hard decision for them, I have no criticism for them ‑‑ ‑but they just basically said that they could not continue to keep ‑‑ sustain this OpenSource with the funding that they had.
And they posted a blog and announced that they were archiving their OpenSource repo, there weren't going to be any more OpenSource versions and all subsequent versions would be subject to this commercial licence.
So everybody on the team was, we were all on chat and everybody goes and reads the blog and we were thinking, well, you know, maybe this isn't an emergency, this library is pretty stable, it does what we need, you know, maybe we can just take our time thinking about this. And Tomek pointed out, with the rate of LLM discovered vulnerabilities that we are seeing in our software, we couldn't sit around for very long using this component that was no longer maintained.
There was a little bit of a side issue, so on the website they talked about having a low‑cost community licence for individuals, students, non‑profits, non‑commercial OpenSource project and small organisations. And we looked at this and we said common commercial OpenSource project, small organisations, that's us, maybe we can just pay for money for this developer licence and keep using it.
So Tomek sent the project an email saying, hey, we are an OpenSource project, we are a little bit confused, can you clarify how we could use this developer licence? And the upshot was we couldn't.
Even if we had this developer licence, there would be this binary blob, it was not going to be OpenSource, so it would clarify that we could not continue using this library.
TOMEK MRUGALSKI: So, the conditions that they set up would be very uncommon, let's say. So even if we decided to pay, so we would have to pay for all the licences for our developers, OK, so financially this is something that we could possibly afford, but the problem is OK normal OpenSource but every user who would like to deploy would also have to buy a licence, so we would have like OpenSource software that you buy a licence for, so this was like completely incompatible with OpenSource approach.
VICTORIA RISK: It was confusing, maybe it was wishful thinking we could keep using it, anyway, we couldn't continue using PrimeNG without maintenance, paying for the commercial licence wasn't going to be a solution, so there were three logical possibilities and this probably what everybody confronts when they are thinking about dependent libraries, we could switch to another library, we could build our own component library or we could just refactor the whole software, so we didn't need to use any UI library.
And Tomek made a big chart or spreadsheet with other different libraries and what language and anybody in ISC have experience with them, how mature were they, how often did they do releases to narrow down what were the reasonable candidates.
We settled on if we are going to switch to another component library, we decided to prioritise the Angular material library. To build our own component library the obvious choice was to import the PrimeNG components ourselves, I think they were either MIT or Apache licensed.
TOMEK MRUGALSKI: Yeah, the last version would take over basically fork and then copy down
VICTORIA RISK: The last idea was eliminate the component Libraries and build a whole UI up from scratch.
While we are thinking about this of course there was a lot of discussion on the user mailing list and a group raised their hands and said yeah, we want to establish a community fork and in this as an OpenSource project and this was like a brand new idea, brand new effort so we weren't really sure where that was going to go.
Obviously one of our mean concerns was how hard to implement each of these. So different people on the team volunteered to do experiments and try and implementing that subnet table that I showed you in the screenshot and with each of these different options. And these experiments took up several days each and the whole process of trying them took us a whole month.
So you don't have to read all that text, the GitLab issue has all of the results of the experiment, it's actually, it's fairly humorous to read. The engineering that tried this basically did not like this other library and in particular it wasn't, didn't have the same features for handling large tables, it was going to require that we rewrite the components that we are using, the prime N G, UI elements, we would be able to keep some of our tests but it was a little bit clunky. One of the other things, there were some features that weren't implemented in this other library. And just as an example, the highlighting shows you, we had this ability to pin tabs up and the whole point of this is you can flip from one screen to the next and see what's different between two different subnets and this was one of the features that we would lose if we adopted this new library. Obviously if you switch libraries you are going to have slightly different functionality.
The other option, we thought we didn't use very many components, but it turned out when somebody looked, we use a lot more than we thought. And some of the modules depended on other modules and so once you kind of totalled it up, we were going to have to import a tremendous amount of stuff and it was going to be an ongoing maintenance burden forever.
So that would seem like a bandwidth big effort.
And then again we got the GitLab here with the comments, there are a lot more comments. The engineer that tried this really loved it, it was fun. But this was going to be a tremendous amount of work and we are actively adding a lot of new features to this tool and this was going to really delay the rest of our road man.
One advantage of building it from the ground up is that we could replace these components one at a time, we could take our time with it but this was going to be the biggest new development effort of all the options.
One thing that was interesting, I don't completely understand it, but the way that we were pop lay lating the GUI, we exercised API in the product, every time we added a feature or tested a feature, we were exercising API and if we built the GUI from the ground up and weren't using our own API any more, we would have to make a special effort to maintain it. This was just like an unanticipated consequence but I thought it was interesting.
So what about the OpenSource fork. The team behind the fork OpenNG .org were very ambitious, they actually launched their effort a year ago, a year ago in June of 2025 and after a whole year, they hadn't yet announced what were the OpenSource project they were going to adopt and right before all of this happened, they announced OpenSource project they were going to going to adopt and right after that, PrimeTek announced that they were dropping support for PrimeNG so yeah, we just, we weren't convinced that this was going to have enough support.
So just to summarise the result of the implementation experiments.
Using Angular, we would have to reimplement a lot of features and we would lose some features and in particular the table handling which was one of the most important features for us, the engineer had choice words for that part of the component.
Importing the components ourselves, what's the whole point of using a dependent library, you don't have to develop it and maintain it, that was going to be a huge ongoing maintenance burden.
And the last option even though it was described as fun, it was going to be a huge amount of work.
But while we took this month to experiment with alternatives, the people behind the OpenSource fork were busy.
They somehow accumulated 700 stars on GitHub which is kind of a big expression that there were a lot of other users that were interested in supporting this effort. They wrote some documentation and they're imported all the old issues from the PrimeTek repo which kind of indicated they were serious about maintaining the product at a high‑level. They started writing documentation and issued two releases, an initial release and one with some bug fixes.
TOMEK MRUGALSKI: Now there are 11 releases, it looks pretty good and the numbers are a bit out of date, so the number of stars is close to 800, so this is a good indication that there's interest in this project and it's taking off.
VICTORIA RISK: So the decision, going with the OpenSource fork was always going to be the easiest option to implement and just by waiting a couple of months ‑‑ we weren't waiting, we were actively looking at other alternatives, but we were able to see enough support around the fork that we were comfortable going with it, here's a timeline, I don't remember when in here we said we propose this talk, but I know when I proposed this talk I wasn't at all sure how this was going to come out. But luckily it seems to have had a good result, actually.
So, anyway, we did just two weeks ago I think we released the Stork 2.60 version, that included some new features and also included our migration to the Optimus UI community fork.
So this is just rank speculation ‑‑ I don't know anything about this really ‑‑ but we all know that ‑‑ well, I don't know, I personally have tried vibecoding a website with an LLM, I think this may be one of the areas of the software business that LLMs are coming for first. You know. I don't know, but it could be that the added financial pressure on PrimeTek and also we have seen that the Tailwind CSS project seems also to be exhibiting signs that they are having financial issues, you know, this might be sort of a leading indicate core of a part of the software business that's going to be challenged. Both of these though are component libraries used in creating end‑user products, so end users don't even know they exist.
So what we learned from this, we got lucky with the community fork. This change could have really caused a major unplanned refactoring effort, we really could have delayed our roadmap by months. And I personally I feel sad that this library ‑‑ we weren't supporting them, I had never contacted them, you know, it was a very popular library, a lot of people used it, it had been around for ‑‑ it was quite mature. And we have a product that's dependent on this library, and I feel like we have a responsibility to support the people that produce those libraries. Even though we think, oh, we are small and non‑profit, you know, we don't want to be part of the problem. So our management team in talking about our budget for next year has explicitly set aside money to support some of the libraries that we depend on with financial contributions. And I don't want to pat us on the back because we should have been doing this already, but anyway, we really get the message.
Here are a couple of references. As I mentioned in the presentation there are links to some of the GitHub issues where we discussed discussed our analysis of the options.
Anyway, that's it, if you have any comments or questions.
(APPLAUSE.)
MARCO SANZ: Thank you very much.
Very beautiful story. Thank you.
NIALL O'REILLY: Apologies to everybody, I just noticed I am not dressed properly, I have no badge. It's inexcusable, so please, please pardon me.
Vicky, you mentioned that you suddenly you realised you had an obligation to some OpenSource provider that you were utilising to build your OpenSource stuff. I was thinking only the last week or ten days about exactly this. There are some OpenSource projects or their intermediaries‑‑ and I am thinking in particular of David Caldwell who makes Emax nicely packaged for the Mac but there are one or two others. Privately as an individual, I can't be giving five euro a month to all the things I would like to support.
And I wonder whether you thought of either taking an initiative or promoting an initiative from somebody else to put a bucket somewhere that we can all throw a euro or two into on a regular basis and have it divvied up among all the projects we would like to support, because they make my working life or my private life possible?
VICTORIA RISK: I don't have a list of those handy, but there are at least a half a dozen efforts that have come up just in the last year, where people set up an organisation for the purposes of raising money and redistributing it, and each of them gets, you know, maybe 800,000 dollars or something. There's no shortage of organisations that are willing to pool this money and give it out; there's a shortage of money going into them. And you know, with a couple of minutes and a Google window, I could get a list for you. But there are a bunch of these out there. Just the amount of money that they have to give away is grossly inadequate.
And I know people are very excited about efforts like this, the sovereign tech fund and I personally have written grant applications sometimes to support some of our OpenSource development, but I do feel strongly is the best way to fund OpenSource is the people who use it, who know what's important, the people who use it should support i,t and we shouldn't all be looking for the government or someone else to pony up.
NIALL O'REILLY: Yes, I'm glad there are already such aggregators or intermediaries, and thanks for raising my awareness and you can help me do that Google later maybe or put it into the mailing list. Thanks very much.
VICTORIA RISK: Somebody else can hop up at the mic and list off a couple of them but there's ‑‑ it's not just the Github sponsors and Patreon, there's a bunch of other initiatives. The problem is there's in the enough money going into them.
MARCO SANZ: Mailing list is the better place. No further questions, anything from Meetecho Marco? Nothing. OK, then thank you again for sharing.
(APPLAUSE.)
And any other business? I would like to ask Niall to come on stage.
NIALL O'REILLY: I'm Niall O'Reilly. I do most of my activity these days through a small company called Tolerant Networks. I want to mention two things. One is to remind you that I gave a lightning talk in the Monday plenary at Edinburgh about Cascade funding, which comes from Brussels. If you have forgotten about it or weren't at Edinburgh, remember that if you have a project that fits the profile, Brussels has money for you. And the intermediary for this is an NLnet foundation, visit their website, NL‑NET.NL
A.
It's not the same as NL‑NET labs. And find out whether your ‑‑ what you are doing would qualify for assistance from Brussels.
They are an aggregator perhaps of the kind I mentioned because they are taking all of our tax money and making a small amount of it available for OpenSource and they have the slogan "public money, public code."
And in addition, following on from Barry's mention of the lead curl maintainer as one of the heroes of OpenSource, he helped by James Rice, he sent me a bunch of curl stickers, you may have seen some on the table in the coffee area, one of them if you are wondering what it looks like has an image of his face. If they have all been snatched already, there are still more in the drawer in my room and I will be putting them out in the coffee area again tomorrow and if you still don't get any, hit me up. And if you want one, don't go away without one. That's it. Thanks.
(APPLAUSE.)
MARCO SANZ: OK, then with that, we have come to the end of the session. I have still two ‑‑ no, no,
AUDIENCE SPEAKER: I have one or AOB, I have two extra tickets for the RIPE dinner, if anybody needs one, come and see me.
MARCO SANZ: That's very nice of you.
Final announcement: The voting for the PC election is open until Thursday 5pm and the deadline for RIPE NCC members to vote in the general meeting is today at 2pm. RIPE NCC members can pick up their sticker to enter from the Registration Desk, they have until 4pm.
That is everything. One more...
NIALL O'REILLY: I don't think I mentioned the curl heroes name, he is called Daniel Steinberg.
MARCO SANZ: That's a very well known one.
We are done, we are done. Thank you very much, thank you for staying here, thank you for waking up‑and‑coming here at 9am.
And long live OpenSource. Bye bye.
Coffee break.