RIPE 86

Archives

Connect Working Group

At 11 a.m.:

REMCO VAN MOOK: I appreciate we have had a bit of a gap in the programme this morning so we are going to try to catch up, if there are people you are missing, send them a text, even if they are not here, send a text to your loved ones, it's important!

I was promised no fire alarms but no guarantees obviously but my sincere apologies in advance.

So, once again, welcome to the Connect Working Group, your second most favourite Working Group in the RIPE meeting, we appreciate you have many Working Groups to choose from and we are thankful for you choosing the Connect Working Group to attend.

Let's see, important things this room has eight emergency exits, one in the front, two at the sides and four in the back. I will be your co‑chair together with Florence and Will and we will be guiding you through these proceedings today.

Yes, show of hands, who has read the minutes? You have all read the minutes, haven't you, come on. Show some appreciation for the scribe. And does anyone have any comments on the minutes? Will, what did I tell you last time? You have out done yourself, anyway.

Good. So, no comments on the minutes then the minutes are approved, other housekeeping items? I am just trying to ignore what's behind me. Don't forget to rate the talks, is also a good point. Is there something else I am missing. Yes, we have a scribe Martin from the RIPE NCC will be scribing this session or he is going to be using ChatGPT. Maybe we will invent some new standards. With that, we are through the housekeeping agenda anyone? No, so let's start with the first presentation, I think.

This is the agenda. Which I am going to be reading from my phone. So we have done the opening and the housekeeping and then we are going to have a presentation by Louis on mapping the geography of data in Central Asia followed by introducing a common policy for the use of IIRDB by Stavros and there's a lightning talk by Silas who will be joining us by remotely. A Euro‑IX update by Bijal.

With that, I think I am going to give the floor to Louis, welcome.

LOUIS PETINIAUD: Hi, everyone. And thank you for having me, so I am a bit of the black sheep around here because I am far from the technical community, I am a geographer, I am ‑‑ hosting in research centre focused on the geopolitical issues related to the digital revolution or the digitisation of the world, it's very wide subject that ranges from disinformation, information influence, infrastructures as well and that's why I am here.

So, we started this project mapping the geography of the Internet in Central Asia with other researchers including one one other geographer and we got support from RIPE project funding for that. We had two broad objectives which was mapping the Internet of Central Asia at three different levels which I am going to explain right after and we mostly wanted to better understand the connect architecture. Basically, geopolitics can be broadly defined as one given territory when we see networks or when we study networks of the Internet it's really sometimes hard to pinpoint them on a map so that's what we are trying to reconcile. And with that specific methodology question which is we can observe the network from afar but what gaps can we fill by going on the field and we chose a rather simple case study which was Central Asia and we did a fieldwork category study in May of 22.

So, we can map the Internet from afar or from friends in my case, through three different, among others, three different prisms, one is physical infrastructures, so this is rather good but in French map of infrastructures in Central Asia but as we obviously know this is a very limited view of the network.

So the second one is mapping connectivity with BGP feeds which we have been doing for a number of years now which can be used to reveal some of the geopolitical how connectivity works in a given territory or region. So for instance, looking at that can help us pinpoint centralisation of networks and its evolution so this is a map from 2021 but if you look at 2015 case you can see the centralisation of Pakistan and you can see some features such as very limited intra regional connectivity but once you see that you have still quite limited view of what's happening in the central Asia Internet.

If we take closer look at Kyrgyzstan, two of the biggest operators there, and you can see identify some dependencies so here you can see all, most of the providers of Kyrgyzstan above on the graph and you can see the Russians in red have definite importance there. But still, you have a lot of other countries there and so you cannot really see what it is.

Furthermore, BGP feeds are incomplete and we cannot infer data path on that.

The third way is using Internet geographer's best friend because it's very helpful to us to have geolocated devices by design we can use to make measurements and observe some things.

So if you look at Kyrgyzstan you can see some more or less coherent and geopolitically speaking basically data goes faster and not that fast towards the south and east of the country, for a number of reasons including geography ones.

The problem is Kyrgyzstan is what I called RIPE Atlas and one of the things we wanted to do was also to try and find if there are differences between the connectivity of it the northern part and southern part of the country which are connected to the rest of the world through very different ways.

So we did fieldwork in Kyrgyzstan trying to understand connectivity with local stakeholders but to create on‑site measurements to improve the granularity of what we could see.

In interviewing local stakeholders help us to understand why the Internet in Kyrgyzstan is shaped as it is, finding is very strong lack of shared understanding of the region's connectivity so I have a few examples here, for instance there are two IXPs in the south of Kyrgyzstan, one was set up by the Internet Society chapter and with help and coordination with local stakeholders, once they set up this IXP nobody used it because it was a very obvious lack of incentive from local stakeholders, which showed how coordinating takes much more than just talks with local access.

Second is the issue of connectivity with neighbouring countries, when you ask different providers in Kyrgyzstan how they are connected to their neighbours mostly Uzbekistan or China, people have different knowledge of it, some people say there are some discrete connectivity, some way there's none and it's difficult to assess.

And finally there is no contacts between the in central countries of Central Asia. Income operators does not have contact with their peers, not in networking way but with their peers in Kazakstan and other countries there.

The second thing we see was the influence of politics on the shape of the network in Kyrgyzstan. So we met with political actors there that have a very specific view of the network, so I have put a quote, (Russian) when we came to the ministry of information and we talked about dependency to Kazakstan and Russia and we asked, how do you intend to maintain your potential ‑‑ your networks, that was.
Answer: What is digital sovereignty? We are from France and from Europe, where our digital sovereignty is rising issue and we were kind of surprised of that lack of consideration on that especially considering that Russia obviously has very strong views on that as well.

And also this has an impact on how the political ‑‑ the government in Kyrgyzstan manages the networks, basically they don't, and they suggest that the redundancy or the efficiency or even the resiliency of networks are the sole responsibility of private operators and then we suggested that maybe, one of our ‑‑ the invasion of Ukraine by Russia in February 2022 led to very strong changes into the consideration of what it means to be dependent on Russia, it was to some extent, but it was, it was seen as an inescapable fact, basically yes we know we are dependent on Russia but what can we do about it. On the other side, there are some projects that are considered more and more actually ‑‑ more since we left Kyrgyzstan that are considered with interest so for instance this project by Turk telecom to connect to Central Asia and plans are continuing of China, building fractures between Chinese networks and Central Asia.

And finally, one of the last things we did was try and understand why there was so few RIPE Atlas probes and while there were not many contacts between local operators and RIPE or because ‑‑ or why that were not that many ‑‑ that much information on PeeringDB for instance. Those were the three most recurring answer, basically the lack of interest, they don't see the point of doing so, the like of competent personnel because a lot of small operators don't have personal competitiveness to be able to engage in that sort of things. And another lack of certainty about the cost benefit ratio of doing so.

Sorry, I don't know ‑‑ I don't have time left, I think. Okay.

So I am going to it be really fast. The second thing we did is create local measurements so basically with the lack of RIPE Atlas probes there we actually created portal probe and we moved it around going from ‑‑ southern capital and we tried to connect anywhere we could to develop measurements. One time measurement kind of a rudimentary way of doing things but for jog /RAFRS it's already relevance. And we then devised a visualisation platform to analyse those trace routes that could be used for geopolitics for the study of conflicts there. So this is a working in project which is being refined kind of every day actually, which allow us to map so all the sort of measurements on the left from a variety of cities in Kyrgyzstan and I have chosen just Kiev as targets and this is one, this is a way of being able to map in different ways so this is an AS level mapping but we have also rDNS mapping and we are trying to develop a lot of ways in order to tweak the measurements and be able to see what we want to see.

So, I am going to end on that. On potential for improvements and suggestions from the Working Group and all of you

The first one being RIPE Atlas dissemination how to increase and is it a good thing to increase the spread of RIPE Atlas probes including in strategic areas and remote areas?

And could moving probes be efficient tools for communities because this is something we are developing. And we also want to facilitate the manipulation of easurements data so we have a work in progress which is not mine but a colleague of mine who is working, has been working on a tool to be able to better and more easily manipulate those data.

How to prioritise most reliable geolocation data we have in hand, develop this more for visualisation, you see a 3D map which is not that efficient as of now but we are exploring that and possibly the most interesting thing to me is our applicability and reliability of fieldwork as it's also data which will remain open to this discussion, and I will just end up on the fact that I done the fieldwork in Ukraine a few weeks ago that confirmed the relevance of working at this level of granularity and with local actors to understand better the geopolitics of connectivity. Thank you.

(Applause)

WILL VAN GULIK: I see we have got one question from the chat actually, from the Q&A question.

FLORENCE LAVROFF: This is correct, we have a question from Carsten Shefner who are the operators, predominantly state‑run or private, question of the perceived lack of interest.

Who are the operators predominantly state‑run or private?

LOUIS PETINIAUD: Only private operators.

WILL VAN GULIK: I see we have got one question from the queue.

AUDIENCE SPEAKER: Thank you so much for this talk, I think that Central Asia is a very important area where RIPE should focus so I was really looking forward to this. I have a question, I have read the article on RIPE labs and I also found this, I want to know what are the right now actual available alternatives; are there any links between China and ‑ that are in use and could be increased in capacity or something like that or is that still politically impossible?

LOUIS PETINIAUD: Well what we have heard from the ground is that Chinese alternative are not deemed to be suitable for Kyrgyzstan right now but someone recently told me and I have checked this morning, China is finally building its rail roads towards Uzbekistan and there is a good choice they will make use of that to increase connectivity but the problem with China is the quality of the network in the west part of the country which is apparently terrible so before they set that up I'm not sure central countries going to cooperation ‑‑

AUDIENCE SPEAKER: Do you see or have you found something about connections to the south towards Iran or through the Caspian sea towards asker buy January?

LOUIS PETINIAUD: I have not seen that much except for Turk telecom so it's far from being done. Mostly there are plans but they need money to fund them, if I'm ‑‑ if I'm ‑‑ from what I have heard.

AUDIENCE SPEAKER: Thank you very much. I would like to catch you during the coffee break.

WILL VAN GULIK: I don't see anyone rushing in the queues so thank you very much, Louis, and a round of applause.

(Applause)

Next we have got Stavros going to present us a proposal about the filtering on IXPs.

STAVROS KONSTANTARAS: Hello, everyone, welcome to the Connect Working Group. My name is Stavros, I am working for AMS‑IX but this proposal, this draft actually is not Stavros work or AMS‑IX work it is a proposal that came from this group of people, as you can see over here and presents the ideas of several IXPs.

And having said that let's go to the presentation.

So, let's start with some background information first. All of you know that there are five official Whois directories which are established by the five RIRs. And this directories supposed to work as source of truth for us, for all of us, and source of truth to get, for the resource ownership. This information that exist in the databases is expressed in human readable language in RPSL so we can read from information from the resource owners.

However as you know there are some private databases outside which they appear during the past, all those years, for several regions, for example it could be that those private databases were covering the gap that was existing because official was not there, the LACNIC example.

There was also another reason that people created private databases to have some data, local in their network to mirror the databases the official ones and provide shorter response times to the customers but also there was also another need to publish some data, some information, some objects as local authoritative databases to their customers.

So, some resources that create those private databases and we identified it as a group of people.

Let's go back now, let's go a little further now to the current problems that we have as IXPs in the current ecosystem.

Let's say that there is a network, a new network that has allocated resources from its RIR, let's say RIPE, based on IANA we know where this network belongs to or should belong to. In this URL for example you can see that those AS numbers are assigned to APNIC, those AS numbers belong to RIPE and so on and so forth so we know exactly which is where we should go and search for information. Question is, what if this guy instead of going to publish its policy in the RIPE database goes in a private database, if I go to RIPE and then I will search for this policy then I will get an empty list. If I want to create a nice prefix list out of that because the operator went to private database to publish the information.

Or we have another problem: What if the network owner publishes its policy and objects but in public and official database like RIPE and in private database, let's say Level 3.

Question is, is this a scaleable approach if he does this with two, three, four, five databases at the same time? And what if the network owner misses to update one of those policies, let's say he has his policy in RIPE and then its policy also in Level 3.

If he misses to do the update in all objects with correct information then it can result what we call in an object conflict and the proposal we design as opposite conflict, the situation of foreign network resource, let's say aut‑num or ‑‑ exist in different versions in two or more databases. Let's say we have this AS ‑‑ my customers which is in RIPE DB, it has last modified date of February 2020 and if you try to resolve it brings 5,000 prefixes, and then we go and find same AS set in RIPE DB with last modified date of 2023 and if we resolve it gives 10,000 prefixes. Nice.

Then some questions and concerns come out of this opposite conflict.

First of all, which one should I trust for resolution, the one ‑‑ the object that exists in the RIPE database that is official database or the one that is in private one and is the last modified version is newer and brings more prefixes.

What if we rely on private and the database keys the operations, let's say I target Rogers or bell, bring a lot of policies to my tools and then I create a prefix list and suddenly this databases cease operations.

Another concerns is what if I use certain private database to create my prefix list but all the IXPs do the same, is it okay, is it true that all the IXPs in Europe at least, use the same databases to create prefix lists and there is a consistent view of this customer across all IXP networks?

Another concern we have is do the private database inherit all the upcoming security policies, to reduce lately from RIPE database, from does this security policy also applies to private ones?

But before we go into the proposal I would like to have a disclaimer on you that this is not a policy that tries to fix RPSL or creates 3 is not against RPKI, we don't find any conflict with RPKI work. This draft, this policy targets mostly to answer those questions and concerns and try to shed some light. The author has created a policy, a draft, we want to have it implemented in all European IXPses and this says that an IXP operator must trust and use only the following databases for building and maintaining root server filters.

And of course there are other databases we want to mention is the five big ones like AFRINIC, APLIC, LACNIC and others.

There are some game rules that we have inside this proposal. Okay, so we trust those five and what are the game rules? ?

In case an IXP member has registered their policies and objects in different IRR than the one that is defined in the document, the IXP operator has no obligations to deviate from the policy to fulfil the customer will or do an exception for the customer let's say.

On the other hand, however, it is mandatory for IXP operators to use all the listed databases to generate their filters for example if let's say there is an IXP that doesn't use ARIN database to create prefix filters for root server and the customer has its objects in ARIN database, then the customer can go to IXP and say yes, please use the database to get my policy, get my objects, create your prefix filters and then the IXP operator is obligated to follow that.

We have tentative date, this is not a hard date, it's up for discussion and that we would like to introduce this policy 1st January 2014, but of course means there's some consensus in the group and people agree.

We ‑‑ the authors understand that adoption of this policy will result in massive transfer of objects from non‑supported databases to the official ones and this is a massive work, this is a lot of work and needs to be done. There are four we introduce a grace period of 12 months in which the list of allowed databases is actually supplemented with this extra four databases, the RADB, RIPE‑Non auth, NTT, we use them as IXP operators with private ones to create prefix filters but those objects need slowly to be transferred to official databases and this will take some time.

We introduced grace period of 12 months.

At the end of this grace period the IXP operators must drop the support of those additional IRRs and operate filter generation tools that operate only with these five databases.

During the grace period IXPs will make ‑‑ will make multiple best efforts to inform the customers to start transferring their objects to the official databases and informed by mail, informing the website, it's up to the operator.

Just on time. Thank you very much for your attention.

(Applause)

WILL VAN GULIK: I see people at the line, we don't have anything in the chat room ‑‑ in the Q&A yet.

AUDIENCE SPEAKER: What consideration have you given to non‑RIR space such as amper net space which cannot be registered in the RIR databases?

STAVROS KONSTANTARAS: Legacy space and salve fare ‑‑ we had some discussion internally, we had in consideration of the legacy space was most important one, yes, we checked a little bit on the background information of this space and we identify that this is mostly space that is being used by big tier 1 provides, for example cogent and some big old enterprises, HP, Dell and so on, which actually these guys don't peer with root servers. It's really hard to have a tier 1 provider, I don't know if there is a reason ‑‑

AUDIENCE SPEAKER: There is space that will never be able to be put in RIR space but will be on the root server so what consideration has been given to that?

STAVROS KONSTANTARAS: We will do our best. I know the issue, there are use cases, small use cases but should not be an obstacle to go through this policy. I believe that if there's a consistent view and consistent support from all the IXPs eventually something will happen, I know that RIPE has some nice policies for this space to be introduced in the database, I hope there's going to be some future in ARIN as well.

AUDIENCE SPEAKER: I didn't know about those policies, I will look into them.

AUDIENCE SPEAKER: So my first remark is that we should try to push this kind of policy not only ‑‑ not only limit it to IXPs but also to push it to all the network operators to apply ‑‑ make all the operators take part in this initiative because if we don't, there are the operators which will filter in some way, IXPs will filter in another way and if client operators will not move their objects elsewhere it will end up with different filtering rules and traffic patterns and ultimately some of the two parts will lose and it may be IXPs which is not good, it may be the provider which is not good either. One thing. Second thing: Did you consider the fact that in Peering DB for us at least is one of the source of DS sets, there is the possibility to explicitly mention the IRR database, and this is something that we do use and we do honour. I do remember at some point PeeringDB tried to make it mandatory except that well, doing it mandatory without proper announced ‑‑ previous announcement while it didn't work very well, they tried to do it, it was a good thing but not the way they did it, they still ‑‑ there still is the possibility to use it and we should take it into account. And it still does not solve the problem with conflicted objectives in RIPE and AFRINIC, for example, we had cases.

STAVROS KONSTANTARAS: Exactly. For the first comment, I agree but we say let's ‑‑

WILL VAN GULIK: I got an answer for that, I talked to several operators already and some of them were actually pushing this already on the network, they might be able to comment later on so this is going on and some big operator actually pushing that way so I think we have got something coming up and if we got the policy, we also want the incentive to be pushed to the operators and the network and the ‑‑

AUDIENCE SPEAKER: And get their feedback, update our policy if necessary with their feedback.

WILL VAN GULIK: Yes, absolutely. Thank you.

JOB SNIJDERS: Fastly. Not a question, I want to offer some comments in support of policies with this type of objective. People may ask themselves why now? Why 2023? And it is good to maintain some historic perspective, for instance it's only been two or three years ago that LACNIC started an IRR based on RPKI, so hey, they joined the club of providers being able to provide their members are an IRR service. AFRINIC started an IRR a few years ago, a lot of objects go into that one. ARIN split ARIN into authoritative database, unauthoritative database and deprecated the non‑authoritative database, RIPE split its database into authoritative database and non‑authoritative database so all in all, the data quality of the five RIR ‑‑ IRR databases has massively increased in recent years due to community effort which finally brings us to the point that we can have discussions about policies like these. So, I would want to encourage to you pursue this type of activity and do some measurements like hey, what would be the impact on our filters, and I do have one suggestion; on January 1st, I want to sleep, so pick a different date.

WILL VAN GULIK: We will take that into account, thank you very much.

AUDIENCE SPEAKER: Liberty Global. Most of my comments have already been said, you know, legacy address paper that might still be a problem, why only IXPs, because I think everybody should do this. I want to say support for this proposal.

STAVROS KONSTANTARAS: Thank you very much.

WILL VAN GULIK: I am closing the queue after Rudiger.

AUDIENCE SPEAKER: De‑CIX. Thank you very much for your work, I think it makes very much sense, there is one question you came up with the kind of grace period list of supported RIRs

STAVROS KONSTANTARAS: Yes

AUDIENCE SPEAKER: IRRs, rather, so I quickly looked through all of our peering sessions and there are a few which are higher on the list which I didn't saw on your list so my question would be how did you come up with the four supported during the grace period?

STAVROS KONSTANTARAS: This one? How we came up with this list?

AUDIENCE SPEAKER: Yes.

STAVROS KONSTANTARAS: We discussed at least the authors and together with some other people around and we checked the root servers and the customer base and we see well, we have a lot of customers that exist in these ones, in these four databases and a lot of objects that we retrieve from those configure their filters. If we go now and we say okay we don't support let's say as of 1st January those four then going to be sudden ‑‑ it's really hard. Okay. Going also with small ones that exist in the system, I mean we can afford losing some prefixes but we cannot afford losing thousands of unless we don't support those. It is the source of truth, if you go ‑‑ there are several objects from several 100 prices that have ‑‑ are we going to push those people to move to their authoritative ones. The same also with the Level 3 and NTT, the good thing with Level 3 and NTT somehow some clean data over there is not a lot of garbage so for Level 3 NTT was okay. We have quite some customer base, it's somehow clean data. And yeah, that was the reason.

AUDIENCE SPEAKER: So the only one missing on that or the first one missing on that list which is in our databases would know about ‑‑ Al DB

AUDIENCE SPEAKER: It's just about 1%.

STAVROS KONSTANTARAS: It's very small percent. It's easily to persuade those to go but the RIPE DB has 20%,

WILL VAN GULIK: Rudiger, make it fast, please.

RUEDIGER VOLK: That's difficult. Yeah, well, okay, usual complaint: RPSL was fine in the previous millennium when it was designed, but well okay, it is essentially broken and one part of a brokenness is that for now two‑and‑a‑half DK its people have been using it and not recognised that every time you do a reference to IRR, you actually have to say which list of databases should be used and for your policy in that regard there are still is the question open in which sequence that the databases should be searched

STAVROS KONSTANTARAS: None. It's very easy, you know that the customer has AS, 1234, you know by IANA that this belongs RIPE NCC, then you go there, right?

RUEDIGER VOLK: And for everything that is not resolved there, you just ‑‑ you just say for every customer, you know which should be the first database to search, well okay, the interesting conflicts may be in the later. On the other hand of course, doing a policy were actually a very limited set of hopefully good quality databases is ‑‑ you have the restriction instead of the old time thing where well okay essentially, people were saying well okay it's in the IRR and it may be some obscure strange thing in the out back of Australia, well okay that's removed by this let me just add one forward looking suggestion. I always have explained IRR is a fuzzy defined set of databases of unknown quality, and one is supposed, when one is using RPSL to deal with that strange and uncontrolled diversity. For some good data, coming in from a different source, it doesn't change the complexity in dealing with stuff if you get an additional source that has definitely good information and actually the RPKI radio ROA information can provide that mapping that into IRR structures is straightforward and when I was talking with customers actually I hated to tell someone please do the RPKI ROAs and do IRR, my suggestion would be, improve your tools and your policies so that at least for the route objects you just say well okay, ROAs that are out there in RPKI can be used as an additional source and your customers who actually do the RPKI do not have to bother managing, in parallel, the same information as IRR root objects.

WILL VAN GULIK: Thank you.

Alexander: Thank you for your presentation, I in general support what you are proposing, I have a question: SPO as far as I know there are transfers between IRRs, how the system should solve this situation because the IANA data and what is exactly in the IRR, what is responsible from can be different.

STAVROS KONSTANTARAS: Object transfers you mean mirroring or transferring because it changes ownership?

AUDIENCE SPEAKER: Because it changes ownership between different IRS, as far as I know I can transfer address space from RIPE region to ARIN and backwards.

STAVROS KONSTANTARAS: Then I guess this transfer of objects will result in a new customer that bought this space from ARIN, then comes to RIPE space and then is belongs to a new customer and this will be depicted in the RIPE database

AUDIENCE SPEAKER: If I can transfer an autonomous system number?

STAVROS KONSTANTARAS: Let me think about it. It might be another customer, not an IXP any more, right?

WILL VAN GULIK: I think we should check it. We will ‑‑ I suggest we at that thank off‑list because we are running short.

AUDIENCE SPEAKER: Very small comment, what you are trying to do, you are trying to write best kind of practices inside RIPE policy. I know that there are ‑‑

WILL VAN GULIK: No. We want to publish a document and suggest a way to do things for the community, we are not fixed on the type of documents so RIPE document is not necessarily a policy.

AUDIENCE SPEAKER: Okay. Nay, I have better place to put best kind of practice is IETF, I do understand this community has some uneasy feelings to this organisation but maybe there's an opportunity kind of fix it, thank you.

WILL VAN GULIK: Last one.

AUDIENCE SPEAKER: Benjamin, thank you very much for the presentation, we have been encouraging our customers for some time now to draw up authoritative databases for one principal reason is transit provides already planning to draw up support for a hard deadline this summer. One of the biggest issues we are facing is not only convincing our customers to do so but because some of them didn't manage their entries and relied on third parties to actually create proxy registrations for the databases.

STAVROS KONSTANTARAS: Yes, there is this issue and I don't agree on that. Let's see what you can do. It's hard to ‑‑ I agree on that, but I believe that if we have some common effort from all the IXPs I try to convince my customers will we do the same, France‑IX will do the same, just start doing their job that they should have done already for some time before and then if they start doing that then all of us will start benefitting of that so they can do the job once but if we all of us follow the same procedure or policy then all of us will benefit and that, I think this is a good result for everyone.

AUDIENCE SPEAKER: One last comment, I am a bit worried that the proposed timeline is a bit short for big organisations, even if they haven't already stated, even with transition period might be a bit short ‑‑

STAVROS KONSTANTARAS: It's up for discussion, right. This is the proposal and the deadline, it's not a hard deadline it's what we propose but let's take it in the mailing list and discuss it, I see there's a lot of support on that, and let's raise this concern with dates and let's come with conclusion with the dates and it's up to the community, right? It's a community effort, it's not a Stavros or Will or ‑‑ so...

WILL VAN GULIK: Thank you very much, Stavros.

(Applause)

Our next speaker is online and it's a lightning talk and I don't have my phone so I don't remember what it is.

FLORENCE LAVROFF: About Accra‑IX in Ghana.

SILAS PEPRAH: Thank you so much. I am speaking about Accra‑IX in Ghana, we are... kind of so once again my name is Silas, I have project called and then we can reach me on the details ‑‑ ‑‑

WILL VAN GULIK: We cannot hear you, your microphone is be making a lot of noise, can you try to fix that.

SILAS PEPRAH: So once again I bring you greetings from Ghana, and then I would like to take an opportunity to thank the RIPE NCC team for putting all this together and at one place to know what is happening all around the globe.

Internet exchange is being founded by ‑ communications past data centres.

So, Accra‑IX is nonprofit organisation in Ghana and being funded by a team of Internet experts are well‑placed and are building the system for quite some time now and then at the introduction of the Accra‑IX we are going to help grow more local traffic in the region and encourage around the globe to come into the region and then peer and connect to the various providers we have around and in the region.

Now, why ac/KA IX. Over the years so many issues when it comes to Internet in the region where most providers, most enterprises who have issues with... and service providers also do have issues with high ‑ connectivity when it comes to their deliveries and their connectivities and then this has also caused high bandwidth, I mean now bandwidth ‑‑ in country because content is not ‑‑ out of country, everyone seeking out of the region and then get all this... they have basically impacted the life of users as in the digital life of the users because we mostly also do... services and then I can measure LIR and reliability of content affecting mostly ‑‑ in the region.

Now, with our solution we are as an IX we are providing a platform for all the IXPs to peer and exchange local traffic among themselves and also have to encourage the various CDNs Cloud and enterprise to peer at exchange and by this one of the greatest things we seek to achieve is to be able to reduce the cost of international transit and improve the visibility and service for the users within the region.

... IXP in the region, however due to partners we have been able to take care of the infrastructure across the operations and for this reason we are saying that the ex‑change is being built by the community and then by the community.

A brief history.

Ghana has one of the fastest growing populations in west Africa and we are looking at 2.‑‑ 4 .8 million population in... and at 2020 we were at 21 .1 million, which represent about 2.2% growth at the last census which means within the period is actually growing faster and then more people are being born by the day so yeah, gradually we are growing as a country.

Internet users have also grown in 2017 to 16.99 million as of 2022 which represents about 111.5% of Internet user growth over the period this is to encourage the various CDNs who are seeking services or to deliver their services in the region to use this as a measurement to bring down the analysis and know that coming into the region is going to be more beneficial because Internet users are going by the day. Currently in Ghana we have about six ‑‑ we have eight, we have... main one and then come in to Africa.

So one of the ‑‑ a few key came up with is as part of this, to encourage the smaller IXPs to come to the exchange and encourage services or providers to come to the exchanges and to encourage CDNs to come and with our sponsors or funders and then the they agreed to this so why come to the exchange 1 gig, 10 and 100, local... everything is free and then this is actually to help and encourage all the various ISPs, Telcos and everyone to come to the exchange and peer and transact with that you are going to have access to a local contents, you are going to have ‑‑ to the CDNs within the region and then also you are going to have direct access to the eyeball networks.

Some community objectives have a neutral platform for all meaning everyone can come, both service providers, everyone is allowed to come to the exchange. We have peering policy for all community members and then... platform for so from time to time we will be organising educational submit, educational event for the engineers, we are calling in GH NOG where all engineers come together and we bring in the various registries to educate them on the best practices routing policies and all that so it's part of what the exchange is to offer the community.

FLORENCE LAVROFF: Thanks a lot for all this information, unfortunately we need to wrap up so I can give you ‑‑ we can give you an extra minute for you to just wrap it up and we move to questions.

SILAS PEPRAH: So some we can look at reduce latency and better experience and lower data costs.

Also talk of current location, one of the founding members, the facilities... N plus 1 redundancy, meet me room, 2.5 M V A, power will be an issue who seek to come into the region, they have multiple fibre entries, they have 40 plus carriers which means benefit or build direct business with the backbone operators and the has four plus CDNs foretell communication companies and the ‑‑ duties.

So, yeah ‑‑ profile of PAIX data centres... co‑location data centres services in Africa, so currently PAIX and ‑‑ IX is present in to locations, currently in Nairobi ‑‑ seek to expand and which currently working on.

Let's take a tour.

FLORENCE LAVROFF: Thank you very much for this presentation, I am going to check if there are any questions from the floor and I cannot anyway. I don't think that we have anything online as well, and if anyone has a live question end of August last week that's going to be a nice occasion to answer questions. So, thanks a lot, thank you. And.

SILAS PEPRAH: Very welcome.

(Applause)

We can move to our next speaker. The next speaker is Leo Vegoda, that's the PeeringDB update, we have the Euro‑IX update first, that's supposed to be PeeringDB first if you could please put the previous slides. And there we go, thank you.

LEO VEGODA: Thank you very much. So, here is a marketing blurb and our marketing data statistics from yesterday, we are pointing at campuses and carriers, they are new, low numbers right now but we hope that's going to change, before we get to that, a little bit about the people. Bijal and Patrik stood down from the board after years of service, Rahul and Olivia were elected in a competitive election and we have new offices. Aaron has stood down from president to vice‑president and Chris is looking to leave as secretary and treasurier, there has been an announcement about the skills and requirements of that position, look on the announcement list or just grab me or anyone else from PeeringDB who is here and we can tell you more about it.

We are also looking for volunteers for all of these committees, I have put some words about the kind of thing that you might want to offer, if you wanted to join one of these committees, please take a look, if you are interested join ‑‑ send a mail to stewards and we will get back to you, we have had a slew of people join in the last couple of months but we are definitely looking for a few more.

When we started running annual surveys, one of the first things that we heard was documentation, what documentation? We now have enough that we need to put it into five categories, but that doesn't mean that we have enough, though, it's entirely possible that you think how do I do this thing or why should I do this thing? And we need to write a document about it. So if there is anything that is missing, please let us know and we will do our best to write some documentation that meets your needs. We also have a blog where we explain why we have done what we have done and hopefully why it's useful and of course if you are just interested in the general what it is that we have done over the last year, we have a product report.

But now, the meat and potatoes, the new carrier object, this is an object that describes high capacity layer 1 and Layer 2 links into facilities, at the moment it's a bit manual and that's why the numbers are low. I have just scheduled the work to add in the automation and that will significantly increase the number of carrier objects in the database. Essentially, we are going to transform it so it's very similar to a network object, of course describing something different but the process will be very similar.

We deliberately introduced this as minimum fibre product. We are looking for your input on how we can make it more useful to you. Obviously automation is one step towards that but there's definitely product feature, growth that could make it more useful to internet exchange points to networks that have network split between multiple facilities, all sorts of things like that.

The other object that we introduced earlier this year is the campus. We discussed this for a long time and eventually agreed that we are going to define a campus as cross connects between different facilities, with a common ownership, so you don't need the carrier. So, we have an example here, if you have a campus of facilities and you haven't registered them in PeeringDB then you are welcome to. One of the things we are also doing is, we are going to be introducing a KMZ file that describes the location of all of the facilities that are in PeeringDB, that is going to provide us with opportunities to do a lot more, both the carrier and the campus object really need to be integrated better into our website and so there's a lot of opportunity there to make these not just describe what's available but make it much more useful to you.

So, the other thing that we just introduced like it went into production yesterday, is a V2 search. I have deliberately shown this on a mobile, you will see there that it says hey, if you have got feedback please click here and give us some feedback and I would definitely encourage anyone who gives this a go to click on that link and give us even if it's just one line of feedback, what's good and how could we make it better.

The idea with this is that you can use some natural language terms, here is the example of a facility search for this city, Rotterdam, of course I put it on the mobile site because you can go and see that while it does show there's definitely room for improvement in the web interface there as it is on a mobile device, so these are things that we are looking at.

We know that we have put the carrier object in, we have put the campus object in, we are trying to change search, we need to integrate all of this and we need to look at the website. We know a lot of uses on desktop, it's only 20% mobile. We have a feeling some of that is because most usage is during the working week and so people probably do it on their desktop computer but maybe it's because people don't really like the mobile user interface and so we need to improve that.

But I'm looking here at the desktop user interface and there's some marketing blurb and some recent updates to tell you how fresh the data is but maybe this isn't useful to you as in you don't necessarily need to know which of these carriers are new and so there's opportunities for us to make PeeringDB more useful to you as a user, if you are logged in, you know what PeeringDB is so you don't necessarily need that marketing blurb. If you are logged in maybe we should be doing you a dashboard and it have some saved searches that you have selected or other things. Please contact us and say these are the things that would make PeeringDB a more useful website to me so we can go and put these into the design process and really make your experience smoother and better.

One of the things we have been thinking about is perhaps now we have this campus object maybe we should be showing some maps and show which facilities are there, which campuses are there, which campuses are connected by carriers, that sort of thing. Let us know what would be useful to and we will integrate that into our design process.

So, what's ahead? Well, we want to build out the carrier and campus objects, we want to make the website work better for you. We have a series of releases planned over the next year. You can see her we published the internal testing date and that's also because you can write software that is integrated into PeeringDB. If there's something that is on the issue list that's ready for development, and you think I'd really like to get this in sooner rather than later and you are a software developer you can develop for us and so that's why we are putting this information out there. And if you aren't a software developer but you want to know what has been released recently, our release notes page does describe all of the recent changes.

We couldn't do any of this without our sponsors, we are very grateful to them. They make all of this possible and PeeringDB is completely supported by sponsorship but that's how it works. So thank you to our sponsors.

If you have questions then if there is time, I am happy to take questions. Otherwise, if you need support, we have a support address and if you have got a feature idea, please let our product committee know and we will ‑‑ we will discuss product ideas with you.

(Applause)

NURANI NIMPUNO: Thanks, Leo, good presentation. I really like the campus category, so I was just wondering is that something that's self‑defined or do you have a definition of it under what entity with a cross‑connect or how does that work and what is sort of the moderation process then?

LEO VEGODA: So a campus is the ‑‑ if you are in facility A that is owned by the same organisation as facility B and you can get a cross‑connect then it's campus. We don't have any regulation in the sense that we are not going to, if you don't actually offer a cross‑connect and you go and say you are a campus, we are not going to do strong interrogation of what you actually offer. If you go and misrepresent yourself on PeeringDB, the community of people who use PeeringDB will notice and they will go and speak to each other. I don't think this is something where us vetting the data heavily ahead of time is actually going to be more helpful than the community managing the reputation itself.

NURANI NIMPUNO: I was not asking for some moderation of it. So yeah great. And the other thing I was wondering was, do you do any outreach to, you know, data centres that run campuses and who might not be aware of this saying, hey, are these ‑‑ these look like they might be part of a campus, maybe you should you know add that as a record?

LEO VEGODA: We have written a blog post and done social media and I have spoken to individuals but the last part of the outreach is coming here and speaking here and I am confident that we will be attending other events and speaking at other events. You know, we could perhaps do things like some paid LinkedIn advertising or something like that but our marketing budget is relatively small so if you speak to someone and they have a campus but they haven't registered if you could let them know then that would be super, thank you.

NURANI NIMPUNO: I will.

AUDIENCE SPEAKER: Blake: Just saying thanks to the carrier and campus initiatives, are both appreciated, we use this stuff and I will try to make the case for sponsorship and stuff, so thank you.

LEO VEGODA: Thank you.

(Applause)

Now we can move on to our next speaker, Bijal, welcome for the Euro‑IX update.

BIJAL SANGHANI: I am going to give a quick update on Euro‑IX. First I want to get a feel of the room. How many people in the room know what Euro‑IX is? Oh, okay, good.

So, I won't go into too much detail about who we are. We are a member of internet exchanges points, we currently have 70 members and you can see the list of our members here. Our latest members being the layer Switch IX which is based in the Netherlands. We also have patrons, we have got two new ones this year, Adtran and Renew Tech, so we welcome them. And our patrons are organisations that work closely with internet exchange points or want to have some kind of closer relationship with the internet exchange points so they are equipment vendors, optics providers and data centres.

We hold events, we have a two member ‑‑ membership events a year. We have also started doing, now that we are post‑Covid started to run a couple of workshops, I am going to talk about one of those in my talk a bit later on. We have provided a number of services to the membership and to the community and these include reports so we have an IXP report which is public and that's going to be going out for in the next month for last year's report. We do newsletters which are now quarterly so if you are interested in hearing about what's going on at IXPs feel free to subscribe. Of course we have mailing lists and they are for members but we do have some mailing lists specifically the root server mailing list which is open for root server developers and other interested in root server work.

We do benchmarking report and I have already mentioned the Working Groups.

We are also working on a number of tools and project which are for the community and which are also led by the community and worked on by the community. One of our biggest projects is the IXP database which I will talk about a bit later on in detail. We have a Peering Toolbox which I am going to expand on in a bit. We have a fellowship and mentor IXP programme and this is for IXPs that need help or support so the fellowship programme funds IXPs to attend the Euro‑IX meeting where they get to interact and network with over 40 internet exchange points during a couple of days which is extremely valuable.

We have also ‑‑ and the mentor IXP programme is there for IXPs that need any help so if they are looking for specific help on a topic they can come and say we need help in this area and Euro‑IX we will go out and find an IX that would be well suited to help you achieve the goals that you want.

We are ‑‑ we have a root server large BGP community list and you can find this on the Euro‑IX website and we released a film that was done last year, so anyone wanting to learn a bit more about IXPs please feel free to go and see the film.

So during this update what I do is I send a message out to our members' mailing list and I ask them if they have any updates so I have got a couple of updates and then I am going to talk about some work we have been doing in Euro‑IX in a bit more detail.

First up, we have DE‑CIX, the latest news is that they have migrated to peering LAN 2 which is based on EVPN. And this is obviously improved security and robustness for their locations, except for India. They launched DE‑CIX Cloud router to support direct data transfer from the different hyperscale Cloud provides and a couple of the DE‑CIX IXs have reached peak traffic and specifically DF W, New York, LIC and Frankfurt.

So that's the update from DE‑CIX.

We have an update from Moscow IX, they have their first implementation of BGP rolls which is RFC9234 and that was implemented in March 2023. They will also implemented a BIRD daemon where they have had a couple of issues but that's all fine now.

They have got close peering groups started at the IX and this is isolation for corporate and business peers and protection from DDoS attacks.

Other topics at Moscow IX, smart customer notification about BFD ‑‑ BGP sessions and prefixes and the DDoS protection which is based on Flow Spec.

Next up we have Stuttgart IX, and the update from Stuttgart is they have had a new speak traffic at 122 gig, and 29 peers with 825G connected capacity.

And they are preparing currently for EVPN and VXLAN 25G and 400 gig ports which is expected to go live in Q1, 2024.

An update from MIX, the Milan internet exchange, they have also had a traffic peak at 2.8 terabits, they now have 10 points of presence and three IXPs in Italy, two new points of presence and two IXPs in Rome and and that's due to go live in Q3, 2023.

And focused on development of regional interconnection hubs.

They have also extended the broadcast domain on their main peering LAN which will be done by the end of this year and they are offering BGP training courses for members also in 2023.

And last but not least an update from LINX, LINX have partnered with Equinix at LINX nova in America, there has been expansion at LINX Manchester to Atlas edge and a new strategic partnership with Africa data centres.

That's all the updates from the IXP. I see I am running out of time so I am going to try and speed it up.

A quick update on the IXP DB, so the IXP database is IX‑F initiative and it was represented by lack IX, Af‑IX, Euro‑IX and together we are working on a database, the IXP database, which is fully automated, it's a community‑driven schema that allows IXPs to report their data and I think this is the key thing here is that the IXPs are reporting the data automatically to the IXP database. There is no other input, it's just from the IXPs.

It includes lots of information about the IXP participants, that IXP locations the hardware and root servers also that are used at IXPs.

If you are interested you can find the schema and the documentation on GitHub and you can also add if you are an IXP add your URL to PeeringDB.

Coming soon we are working on visualisation and maps for the database, dynamic filtering, downloadable data sets which you can already do, now you can download any data sets so if you want to search for IXPs or looking for AS numbers or we also have a compare function where you are able to actually compare different IXs and you can see what ASNs at present at one IX or another, so all present at another so you can look at where there is a common ground between networks or IXPs. And all of this information is downloadable.

So we continue to build a data pipelines and we will be working on securing the ‑‑ the actual database and upgrading to some new software and doing all those fun back end things that you can't forget.

There is a mailing list for users, like I said you can find all the information on GitHub and and there is an app I and there is a website and there's also an admin team so if you have any questions or you want to find any information in the IXP database that you can't find feel free to contact the admin team.

The IXP database is also fully sponsored so we don't use any of the Euro‑IX resources for funding this project, and so I would like to of course thank the sponsors because without them we could not make this happen so thank you very much to the sponsors and if you are interested in sponsoring this wonderful work that we are doing, feel free to speak to me, drop me a mail or catch me here.

The next project I am going to talk about is the Peering Toolbox and that is a community focused learning tool. So, as we know, the way that traditional transit and ISPs has changed over the last 20 years, you know before the ISPs would provide Internet transit to organisations and it was quite simple. But what's happened is that the growth in the importance of the Internet to business operations is driving more enterprise networks to manage their own connections and to the Internet which also means joining IXPs so we are seeing more and more enterprise networks joining ISPs. Now it's more to work with there so it's not just one direct connection with your ISP, you are working with multiple peers and also the IXP.

So, what's the problem or where is the challenge? Enterprise networks now take on roles previously which was being handled by the ISP so they are having to learn a lot more when this is all very new for them and there's a lot of questions, like where do I start, what do I need to know, where do I go because there's a lot of information which is scattered around the Internet and there's no one single place where you can actually find everything if you are an enterprise network where you can learn how to stop peering or learn about internet exchange points.

So, this is where the Peering Toolbox comes in, it is driven by the community, it is a Euro‑IX project, we have got organisations involved like LINX and NAPAfrica, Kentik and HEAnet and the idea is to provide a learning structured and best practice information in small chunks so it's easy for people to take in.

I am actually going to speed up a lot now, so we have hired ‑‑ we have contracted this work to Phillip Smith who has over 25 years in training in BGP and IXPs, the beginners section is done, please take a look, Peering Toolbox, you can find answers to what is a network operator, really simple things that we can sit in the room and think oh we know what that is but people who are new into the industry don't.

So, the Peering Toolbox is available now and the beginners section is complete, we are working on the inter immediate section which will hopefully be available before the end of the year.

A quick update on root server workshop that we held in March, we now have a Working Group within Euro‑IX, and we have Chairs, Stavros who is here and Irena into from LUCI X, we had 14 present and we covered automation, monitoring, bird's‑eye and there was a few others.

We did actually take some decisions and the decisions include the community is ‑‑ was in favour of supporting the restriction of the amount of BGP communities that can be used per BGP feed. It was agreed to simplify it allow the and max of 500 BGP communities of any type and per feed. The members were in favour of deprecating and stop using extended communities on root servers, and there was support only for the standard and large communities and like I said the large ‑‑ the list of the large communities is available on the Euro‑IX website so if you want to see what that is you can.

Other decisions taken, RFC1997 BGP communities, there is a strong consensus on keeping them transparent on the root server, no strip and no react and IXP manager is already doing that so for IXPs that are using IXP manager it just makes it much easier to follow this.

My last slide. Regulatory Working Group. So we also have a regulatory Working Group within Euro‑IX now and this came about really, I guess you could say the regulatory Working Group started working at the end of last year, when we wrote a letter to the EU on the SMP fair share debate, as an association for European Internet Exchanges where our members' primary business is interconnecting we wanted to share our concerns on what was being discussed so we did that in January and also on Friday we did also submit a response to the survey on the consultation and we responded to Section 4 which was specifically on the fair contribution by all digital players.

And that's it. Thank you.

(Applause). Are there any questions?

REMCO VAN MOOK: All right. Any questions for Bijal? Going once, going twice, I am going to say the magic word after this but please don't forget to rate the talks, with that, thank you all for intended and it is now the magic word, lunchtime. See you next time.

LIVE CAPTIONING BY AOIFE DOWNES, RPR
DUBLIN, IRELAND