KURTIS LINDQVIST: Welcome back everyone. That's the little coffee break that we had.
.
So, we're back on the agenda, running a little bit behind.
.
So, we're going to dive straight into the next presentation, which is on the Cloud infrastructure by Kaveh, so over to you. And as usual we do the Q&A in the question session.
KAVEH RANJBAR: Hello everyone, my name is Kaveh, and today, with Razvan, we are going to basically present what we are doing with the Cloud at a higher level. Felipe mentioned two of the services, RPKI andd WHOIS, but this is the setup that we have for facilitating, basically, migrating services from the Cloud. I see Razvan is trying to load the slide. In the meantime, I wanted to say I really miss seeing all of you in person, so I hope the situation changes soon and I can actually see your faces and shake hands.
KAVEH RANJBAR: Let's start with where we are today. At RIPE NCC, our main aim is stability and persistence as a registry and, basically, network coordination service we really want to make sure that our services, and whatever we provide, is persistent and reliable so you know that your registry, for example, your record of resources, you can get back to them in, I don't know, in a year, five years or ten years.
.
So, with that, that's a very high level goal. What do we aim for is availability and, of course, security.
.
Achieving this one can imagine two high level paths. One is to scale up, of course, our own infrastructure, which we constantly do with, and we are normally even have this capacity for most of the services to be able to sustain even normal attacks, not some of the newly‑heard crazy DDoS attacks but we really have a good infrastructure, and we scale it up.
.
And the other path is to make use of distributed third party infrastructure, like what Cloud providers do, or a mix of these two, off course.
.
And after consultation with the community, I think first time we really talked about Cloud was RIPE 80 and then a few consultations with RIPE 81, and, of course, now and then there has been multiple threads in the mailing lists, so we have seen what Cloud can offer for us and we also understood the risks and the limits of what we can get from these platforms.
.
So, basically, based on that, what we are trying to, or our strategy, basically, is to use a structured and well defined security‑centric approach to migrate all infrastructure to the Cloud as we see fit. Of course, this is a nice soup of buzz words, I think you get the message. The idea is, we really want to make sure, when we build up new services, we also consider if we can use Cloud providers for that or not. And pursuing that, we really have ‑‑ our aim is to have three goals, or keep an eye on these three important goals.
.
One is to include the resilience of our services. We also want to become more agile and flexibility. We want to focus engineering expertise on our core business.
.
I will go through each one of these quickly.
.
So, more resilient services. Of course we want to improve our resilience. We know and you know some of our services are critical and some others may be not operationally critical but still important.
.
We want to increase our global presence, and of course that would lead to better local access globally and we also want to have the desired control sets of what we want over security and reporting of usage of services.
.
So that covers goal 1. Goal 2 is more agility as an organisation. We want a faster, easier safer approach to gain experience experiment with new services. Most of you have seen Christian's presentation before which he also mentioned, for example, with RIPEstat, that we also want to experiment if there are possibilities with machine learning to provide some additional service. So with something like Cloud at hand and data being there, it's really easy and fast to try some prototypes to see if it's worth pursuing.
.
It can also allow us to adapt to changes in an environment quickly. So if we need to scale up a service because of usage, it becomes popular, or if we need to scale down, of course we can do that fast.
.
It also means it needs less time for public release of new services because we can easily integrate our Cloud providers and then any number of them to our development process.
.
And finally, because there is generally pay as you go model, this avoids over‑provisioning or actually makes capacity planning much easier and rational and also reduces investment in owning hardware. So, of course there will be opex, but we will have more control over that.
.
And then finally we would have improved cost visibility.
.
And then, finally, it will provide us with focus on our core business. Basically this means we can employ more of the organisation engineering expertise instead of looking after hardware and things like that, we can focus on our core business being a registry, providing data for our members and things like that. We have some top‑notch engineers and we want to use their time to work on what will be provided to our members and the community.
.
And, of course, related to that, that increased productivity, because we will make more efficient use of our engineering time, and finally, in a long run, we also see this will help to attract and retain access to a wider pool of talent looking into the market for the next coming years.
.
So, basically, next is how all of this will happen, and, with that, I will pass you to Razvan, our senior engineer, who is also a lead of our Cloud efforts, and he will give you detail ‑‑ more details about how we are trying to realise all of this.
RAZVAN OPREA: Thank you very much. Hi everyone. Nice to meet you all again. So, about a year ago we all realised that we needed to organise structural Cloud efforts. We had a sea of little prototypes in various schemes and to put them all together and to bring this structure, we created a Cloud centre of excellence, CCOE, which comprises of members from multiple NCC teams. While currently 26 people contributed to these efforts, to be sure this does not to become their full‑time job. The CCOE is a coordinating group that enables access so Cloud for any team that wants to migrate a service there.
.
How does this happen? Every service is assessed independently from each other. It goes through a rigorous, well‑defined process that includes technical, legal, GDPR, financial assessments, communication, this includes a total cost of ownership estimates. The level of something recommended by the CCOE depends on a case‑by‑case basis. The higher obstruction level in the Cloud means a deeper integration with the Cloud provider, might offer operational and performance benefits but makes the cost of moving out higher. So this is a balance we need to strike and we need to play with and we take this decision very seriously on an application by application basis with any case. Where possible, we prefer technologies that work across multiple Cloud providers, such as ‑ is a high level language provisions infrastructure as a code on which to host applications as opposed to Cloud native ones such as AWS's Cloud formation.
.
As part of this Cloud migration process we conduct a risk analysis and this includes technical aspects such as service availability but non‑technical as well such such as reputational risk or geopolitical risks.
.
Also part of the process for every single application is the creation of proof of consents and planning the engagement with the community membership and the board.
.
This does not mean that we will present here doing during the RIPE meeting for every single application a team might want to migrate and the CCOE assesses. For instance we have been migrating internal business application for sometime and in some cases the vendors were the ones that forced us to migrate. But we will be fully transparent in communicating all externally‑facing applications we migrate. In the case of critical ones, we will announce our plans and consult with the community.
.
Later in this presentation, I will talk more about it.
.
What are the responsibility of the CCOE? The responsibilities are based on three major pillars. One is based on governance, defining the Cloud strategy and the operating model. Sometimes this is referred to the Cloud adoption framework, think of roles of the responsibilities. Financial operations or ‑‑ operation processes. Additionally, we are discussing there the architecture frameworks, best practices and of course the Cloud cost management.
.
Another pillar is the Cloud engineering, where we refer to building, maintaining and supporting Cloud infrastructure and implementing the core service technologies.
.
Finally the third pillar is represented by Cloud knowledge. Supporting engineers that are Cloud schemes and technical analysis and technical support for other teams.
.
How do we select Cloud providers?
.
Every potential Cloud provider needs to be vetted by legal, information security and the finance teams.
.
An essential part of this vetting process means that the Cloud provider must have legal and physical presentation in our service region. The following criteria were used when deciding in a first round to choose AWS and GCP as our first Cloud provider together.
.
First of all, the services is available. So, we had a batch of applications we knew there were low‑hanging fruits and RIPE for migrating the Cloud, and we knew that we needed certain ‑‑ a certain amount of services in the Cloud to run there.
.
But also the number, the global availability of other Cloud sources available to us were important. For instance, we knew that we would need a database but there is a clear advantages with a Cloud provider that also has more type of databases since we have Internet teams running applications that have a memo database.
.
A very important criterion is the clouds providing maturity. So, this means allowing us to build a virtual data centre. Some providers all it a landing zone. This takes the form of infrastructure as code architecture with standard tenancy, accounts in AWS or projects in GCP and structure such as development testing, acceptance of production, which ‑‑...... isolation, and parameters, so‑called guard rails providing, amongst other things centralised security controls, mandatory auditing and logging, identity access and management, network structure, monitoring etc.
.
Another criterion was rate the fact that not knowing beforehand what applications we migrate to Cloud, and how their Cloud architecture is going to look like we did not want to paint ourselves into a corner around we wanted to maintain the ability of running some of the critical hardware such as net upstorage and platforms such as...... in the Cloud. So support for this was very important as well.
.
Finally, we looked for sustainability, the Cloud locations we're using AWS and all the European GCP locations are a hundred percent carbon neutral, experience support and reputation.
.
That being said, we are actively looking for other Cloud providers that would meet the criteria above, that would ideally be based in our service region. We are closely following the progress of projects such as GAIA‑X and we are open to your input and suggestions to possible candidates. So let's have a conversation on this topic.
.
What progress have we done so far? As I said previously, we migrated already some business internal applications to Cloud. Then we started with smaller public services to gain experience, and one of these is the meeting registration software, for instance, for RIPE 82.
.
Then RIPE Atlas measurement data is in Google BigQuery since RIPE 81. It's been a lot of work on this project and this new service allows large scale analysis of RIPE Atlas data and is available to the community to be used now.
.
The RIPE database release candidate environment is another example. This has been migrated as a proof of concept to AWS before RIPE 81, and it had two...... both of them tested in AWS.
.
The details and the roadmap for these will be presented tomorrow in the Database Working Group.
.
We started maintaining for full transparency a page on our website, you can see the link with all the production applications, externally facing applications we have migrated to one of these two Cloud providers, even if we choose another one here. There aren't too many. The list is going to hopefully grow. You see some of them that are RIPE NCC‑related and the meeting live streaming and the meeting platform both running AWS since RIPE 80.
.
Next steps.
.
So, the results from the prototypes, we have multiple prototypes from multiple teams running simultaneously. They are promising. Also the applications we already migrated, their performance is more than adequate. Security controls are fine. There is also promising. We are earmarked more than a dozen NCC internal services and some external ones for migration in 2021. And some of them most visible ones include the RIPE database, the RPKI repositories, read about it in RIPE Labs, and you have heard from Filipe and also the RIPE database.net website.
.
This promising prototypes and the applications we ran so far seen also the pace in which engineers gather knowledge and the progress that we are making, allow us to formulate a data centre exit code, and that is to reduce our dependence on conflicting data centres space and own hardware by three quarters of what we have now, by the end of 2023.
.
All this is being done using some key principles.
.
And that is the following:
.
RIPE NCC will always remain in control of our services.
.
We understand our role in supporting Internet infrastructure. We take it very seriously.
.
Cannot rely on any single provider. And that is the example I gave, our general preference for technologies that span multiple provider.
.
We try to fully mitigate risks such as vendor lock‑in or the potential for political impacts. And this is why we ran with two Cloud providers fully vetted and we're looking for a third one.
.
Critical services will always retain an element hosted with the Cloud provider in our service region or on premises.
.
The RIPE NCC will always be the single point of contact with full responsibility for our services. Nobody will have to talk with the Cloud provider or any of the services they provide.
.
And planning communication and engagement with you, our community, is an integral part of the migration process.
.
Thank you very much. And I will hand over back to Kaveh for questions.
KURTIS LINDQVIST: Thank you. We have a few questions, I will let you agree between you who answers them but I'll read them out in order.
.
So, the first question is from Peter Hessler: "In the case of a Cloud provider is used for production but later is determined to no longer be appropriate for use, has the RIPE NCC estimated the cost of migrating off the Cloud provider, e.g. bulk data transfers cost out to the network and the orders of magnitude are higher than expected?"
.
KAVEH RANJBAR: In general, yes, and for more details of that I will pass to Razvan, I know this is part of the process.
RAZVAN OPREA: So whenever we choose a Cloud provider, the landing zone, the virtual data centre building represents an investment that in case you close this provider, you simply move away 100% you lose this investment, obviously. But for every application that you put in, there is definitely a cost included in generally how much you put in is how much you get out, depending on applications. Some applications you might lift and shifting them, which is the running a VM here, they are going to run in a VM in the Cloud. Some you need to rearchitect. There is a cost in rearchitecting the application, and moving into another Cloud provider means another cost. So the cost themselves are being included.
KURTIS LINDQVIST: Next one is from Randy Bush: "In your test deployments, how dependent have you become on unique features of the Cloud provider?"
KAVEH RANJBAR: Very good question and very valid. We have actually observed that it is really easy to take comfort in using some of the services provided by some of these providers and then basically be addicted to that and connected to this forever, but we have ‑‑ this is one of the very important criteria that we use. I mean, of course we always keep the multiCloud in mind, or we have a strategy with AWS but we have no plans to only stick with one provider or only AWS and GCP. As Razvan mentioned, we want to at least add one, but if there are more opportunities we will definitely look into them. We fully understand it is very easy for vendor lock‑in basically to happen. But my understanding is, right now, what we have in AWS can be deployed in other provider, but of course there is a bit ‑‑ there is always a bit of small change here and there. I don't know if Razvan has anything to add to that or not.
RAZVAN OPREA: There are. We already know one, for instance, one service is BigQuery in Google, it's a pretty unique service, it's hard to match with other providers. The service that we're offering is it exists because of having assess to BigQuery, otherwise this wouldn't exist, it would probably be too expensive to put together pieces from AWS or other Cloud provider. But again, it's on a case‑by‑case basis. So, so far, Randy, probably BigQuery would be one example.
KAVEH RANJBAR: The BigQuery is a new service, it was enabled after uploading measurement data to the TCP‑‑ now, people can actually do analysis on that. But maybe that's a special case, correct.
KURTIS LINDQVIST: The next question we have is from Gert Döring: "Please ensure nothing is ever deployed without IPv6 from day one. Now is the time to make this a hardware requirement."
RAZVAN OPREA: We could probably write it at the moment, a blog article about it. There have been some nice experiences with IPv6 in which we have been pushing Cloud providers such as AWS in supporting IPv6 on some of their services and, as well, reengineering some of the internal services to support IPv6, legacy. So it's a very, very nice and fair point. We take it fully.
KURTIS LINDQVIST: Thank you. Next one is from Nicola von Thadden: "Do you have a backup plan in case you are not forbidden to store personal data with US Cloud service providers?"
I assume this is meant to be in case you are forbidden to store personal data with US Cloud providers.
KAVEH RANJBAR: Thank you very much. We have the backup plan for that, but in general, I mean at least at the moment, the services that were mentioned they do not have personal data, but when that happens and of course this is always a case, I mean not only that we care about it but because we are based in the Netherlands we have to make sure that we follow our relevant GDPR and other related rules, of course this will be taken care of. So, I don't know if anyone wants to add any additional comment. If not, we can move to the next one. But the answer is definitely we have a plan and we will ‑‑ we will make sure that we provision what we store in which country or legislation.
KURTIS LINDQVIST: Thank you. Next is Sander, who is going via video:
SANDER STEFFANN: The first one that appears to me is that, in the blog, it was said that the primary RIPE database would be in the Cloud and the RIPE NCC would host a backup. And that seems very ‑‑ the wrong way around, to me. Like, I have a feeling that the primary should always be in the RIPE NCC's own hands and that, you know, offloading stuff to the Cloud is fine, but yeah, there seems to be a ‑‑ it just feels to be the wrong way around.
KAVEH RANJBAR: May I answer that. So ‑‑ and I don't know if Felipe also wants to jump in but my understanding of what the database team is doing, but by 'primary' they mean the main traffic or the lion's share of traffic will be handled by the instances in the Cloud. It doesn't mean that the main or the main machinery will be there, we will keep something here. Of course, we own the data and we will be in control of data, but when ‑‑
SANDER STEFFANN: The blog explicitly said that the read/write copy would be in the Cloud and that the RIPE NCC would hold the read‑only copy. I would like to see it the other way around.
KURTIS LINDQVIST: Sander, I think Felipe wanted to answer.
FELIPE VICTOLLA SILVEIRA: Thanks for the input. Sander has taken ‑‑ we do expect though that the capacity that are going to have in the AWS will be superior to the capacity we have currently in‑house and that's the main reason why we want to do it the other way around. So expect to have more power in the Cloud than you would have in the power in the data centres, so that's the main reason but thanks for your input.
SANDER STEFFANN: And that's the capacity is a serious problem at the moment. I'd prefer keeping the read/right copy in‑house even though the performance might be better in the Cloud.
.
The other one was ‑‑ that's more like a ‑‑ question on principle. Like, both the Cloud providers currently selected are US companies, and I think we have plenty of Cloud providers in Europe which are even the RIPE NCC's own members. So why are you bypassing your own members in favour for out of region providers? And I'm ‑‑ maybe I am ‑‑ you feel what I mean, you know. Why don't we support the European Internet infrastructure and why do we give our money to a US company?
KAVEH RANJBAR: I think very valid question and a good question. The criteria that was shown by Razvan and maybe if you can go back to that slide as well, we really struggled to find a provider in EU which does that, or covers some of that, of course this is not written in stone, but again, as mentioned in the last point we are open to any ‑‑ if you know provider who can somehow, I mean one way or another, provide and fulfil this criteria, we would be more than happy to investigate. We are definitely open to that.
.
On the legal part that you mentioned, we fully understand. This point was brought up multiple times by the community, and of course we felt it even before, and yes, we understand that, and the more critical data ‑‑ or more ‑‑ I would use the word 'critical data', that we might want to move to Cloud, this becomes more and more important. That said, I think it's important to mention that all of the American organisations from a legal ‑‑ just from a legal perspective, the contract with European basically the European instances, that's we make sure that our data is hosted in European data centres. So whatever value it has. I'm not going to argue that that is solving the problem because it's not. But that's already an additional ‑‑ at least from the legal perspective, that's an additional layer of protection.
SANDER STEFFANN: I know, was it the Microsoft case where the US government just said like even though your data centre is in your Europe, you are a US company, so give it.
KAVEH RANJBAR: The good news is, at least at the moment, all the services that are mentioned and we are consulting with the communities right now, basically these are at the moment these are data publicly available, and you are right, it's an important point.
SANDER STEFFANN: Thanks for listening.
KURTIS LINDQVIST: Thank you. Next we'll go to another video question, which is Anna Wilson.
ANNA WILSON: Hi. Thanks for the presentation. I can see there is a good thoughtful design. You have had to balance a whole bunch of stuff including some weird RIPE‑specific requirements like the bootstrap problem which, you know, I will probably never hit. So good work on that. In that context I actually have my doubts about multi‑Cloud, not for the reasons other people say but because trying to maintain two Clouds plus on premises is a really wide skillset which might make it hard to maintain she is skills institutionally if you also have to go wide. That's a tough one. But I trust you in this. You know your resources. And to my mind, that talent question is crucial. If you want to get the best people, in this day and age we have to use the services that the people we want to hire know and enjoy using. Trying to hire traditional systems today is very different, it's a different pool than it was ten years ago. It's going to be even more different in five years' time. And by the way to the community, I have seen some really insulting stuff in the chat just now basically talking down to an entire sector during this presentation and I think we're better than that.
.
So what I want to say is, the audience that you really need to consider isn't really us today. I mean, listen to us obviously, but we don't know the future either. Us in five years' time are the ones to be really worried about because we are going to be angry about ticket times and service outages and the decisions you are making now will affect that.
.
I believe that the way to do that is for the NCC to get your staff skilled up by deploying these things in a cautious way and by keeping transparent about it so this plan looks to me like it can do that and please keep in touch with us about it. Thank you.
KAVEH RANJBAR: Thank you very much. I just can ‑‑ thank you, and say that we are exactly on the same page. I mean, what we aim for is a communication and the thing is to be honest, it's not like the RIPE NCC at the management or the staff, we really want to go to the Cloud for any reason, correct. We saw opportunities and we see there are a lot of possibilities. Also thinking about that we really want to provide long term services if there are opportunities and if there is basically have I peer pressure or whatever it is, there is consensus that way generally services are provided via chat, understanding our critical role or user unique role and our situation where we don't want to miss on that, because at some point it will be forced on us, I am not saying for everything, but again we have seen it, there is our internal knowledge management system, for example, they have announced, hey, we are shutting down hosts. You have to either migrate to Cloud or say good‑bye, and we might want to say good‑bye. I just want us, the RIPE NCC, to be prepared. Be ahead of the curve and say okay for that reason, we don't want you. So it's all about the conversation. It's all about feedback. There is no, like, hard mandate, we have to do this or that. We want to have a nice conversation with the community, with our membership, and understand how we can together leverage it.
ANNA WILSON: I have been trying to do it for the past two years. It's a hell of a lot of expertise you need to build in‑house and I am glad to hear you've started.
RAZVAN OPREA: I want to add something. That is what the advantages and disadvantages of multi‑Cloud, it's absolutely true that if you are going to lead from on prem to two or three Cloud providers and duplicating what you have inside in two or three places, it doesn't make sense why are you doing this. The point with the multiCloud is that you are not doing this, you are not deploying after application multiCloud. It's just for critical applications you are doing that and you are making these preparations for the internal, let's say, Internet, you won't do that, right. It's enough just one of them. So you are not duplicating everything twice or trice and at the same time you are striving very much to do these landing zone initial investment in the security right of ‑‑ and all the structure that you have in this Cloud provider and then decide on a case‑by‑case basis where goes where.
ANNA WILSON: I hear you. And I was really glad to see what you are either doing active active switch between them or routine failover, and one of those two is really important. So thank you.
KURTIS LINDQVIST: Thank you. We do have quite a few more questions to go through and we all have to join the GM in 17 minutes, so I'm conscious about time to give you ‑‑ so, I don't want to cut this discussion, because I think it's quite important but also I want to make sure we get through all the questions and have maybe a short break before the GM.
.
So, next one is from Peter Hessler: "The two Cloud providers listed are US organisations. How would any US sanctions affect members of our service regions that are affected by them?"
KAVEH RANJBAR: So in the interests of time I think I can just say we fully understand that, we have looked into that and all the possibilities. We have tried to make sure that first from contractual level, again there are multiple levels, we have enough provisions to make sure that that doesn't happen, but in case it happens, we have proper measurements in place that if a service is blocked for example, or access is blocked from a region, using Atlas of course. And second, as mentioned, we are in full control of the service so we can, either for part of the service or the whole service, we can migrate it back to in‑house or others. I don't know if Razvan has anything or I have missed anything.
RAZVAN OPREA: No, it's again a matter of time, Peter. Let's maybe catch up and have a nice chat after this or on the virtual corridors, but I would very much like to develop this. It's just I am mindful of time.
KURTIS LINDQVIST: Thank you. There are some may say only hoped for benefit of the Cloud is the services can scale up and down in mere realtime. Is this something that is really an issue and really necessary critical for RPKI and RIPE database services? I apologise for asking if this was discussed in the past sessions meetings.
KAVEH RANJBAR: So, again, not going into too much detail. My understanding, and I am sure Razvan will correct me if I'm wrong, this is really not a big need at the moment for any of these two services. But of course, we will be able to utilise that and this is a very good possibility to have especially for the larger datasets that we have and yeah, the basically information services that we provide, including RIS data, including what we have in RIPEstat and others, we can utilise that as the backend and scale up and down based on the query node and things like that.
KURTIS LINDQVIST: Thank you. The next one is from Jan Zorz: "Do you expect to start downloading updating RIPE trust anchors from AWS or Google Cloud in the future?"
KAVEH RANJBAR: Yes. So basically, my understanding is none. We aren't planning to deploy a trust anchor or to the Cloud any time soon or maybe never. But it is ‑‑ actually, I just wanted to quickly address something, because I also see another additional benefit in trying to see how we can deal with the repo in the Cloud and related services because as all of, you know, real use of RPKI is where you publish your own ‑‑ so we don't sign stuff for you with your own private key but you actually sign your own certificates, which means that you will have to host your own repo, so ‑‑ and I assume that when you look at scale, many would like to use Cloud. I mean ‑‑ and then this is always a benefit inside systems when you want real high availability if the service chain is usable in the same platform let's say from top to down, or at least you know that part of the top can also be run in the platform that you are running what you have at your premises basically, that that helps a lot. So I think collectively, us the membership and the community, what we learn from trying to host basically our keys in the Cloud can be very useful for the future where people hopefully will sign with their own key at their own place and then publish.
KURTIS LINDQVIST: Thank you. The next one is a question from Erik Bais: Wany requirement if the Cloud provider is actually going to be present in the next ten years with the service and is there a hard cap in the invoicing for the charges of the Cloud provider once the services are in the Cloud? And yes, like Gert stated, nothing can go to somewhere without IPv6 deployment. Please make sure it's a go ‑‑ no‑go requirement."
KAVEH RANJBAR: Let me start with IPv6, because I think it was so essential and basic for us, Razvan wanted it listed in the criteria, but yes it is. And for the service we have in GCP, that the Atlas data on BigQuery we have IPv6 so you can access is over v6. So that's ‑‑ let's make that straight.
.
About the hard cap invoicing for the charges of the Cloud, yes, we tracked that closely ‑‑ of course we are in the coming steps, but we can integrate that to our internal financial system as well which we are planning to do but right now we get quite up to date reports and yes, we have caps and we are fully in control.
.
On the first one, and then again, Razvan, please correct me if I'm missing some point but this is one of the criteria was mentioned by Razvan and we look into that, of course nobody can tell the future but we try to look at the company, the general health, the history and all of that. But that's to the level that we do. I don't know if there is any additional thing.
RAZVAN OPREA: No. There is a financial oversight and ‑‑ but that's the level we go to. So history serves as an indicator for the future in this case.
.
I just want to add one thing, if possible and about IPv6. It's not just a BigQuery part but also everything we have migrated so far is IPv6. So the meeting registration has a AAAA record and is accessible over v6. Indeed it's such a basic requirement that I'm not aware at this moment of any service that we are deploying that the not IPv6 reachable. Those examples that exist are from providers that services we might use that they do not have an IPv6 v6 but nothing that's our control our deployment, Cloud anywhere, this is going to be done obviously.
KURTIS LINDQVIST: Thank you. So, one more last written question then, one more video question.
Dmitry: "Do I read right that the two clouds is considered an option with other being one Cloud and one on premises with a big AA big G looks like no data centre is needed at all?"
KAVEH RANJBAR: So, I think the confusion here comes ‑‑ and that's hard, maybe we should do a better communicating that, because when we talk about Cloud for RIPE NCC, there is a host of services right, it's not only RPKI or who is, we have our internal systems, our financial system our or or knowledge management system and things like that. And it's really depend on the service. So, I don't think we would ever even offer something that if we move all the WHOIS to the A and the G and we won't have anything in‑house, no that would never happen. But it really depends on the service. As mentioned, the publicly available services and critical services, we are just basically ‑‑ we check with you and we want to build something together and realise an opportunity that's there. That's all. So, no, there is no plan to have no data centre or even the goal that Razvan mentioned that's our dependence, so like we want to be able to shed off 70% of our dependents on our local basically data centre capacity but it doesn't mean that we won't have anything or we won't be able to provide our main and critical services without having the Cloud available next to us.
KURTIS LINDQVIST: Thank you. So, last question is from Daniel Karrenberg.
DANIEL KARRENBERG: It's not so much a question. It's just when I see this discussion, I think we all get very passionate about it, and I see a tendency that this gets framed as a conflict or a very heated discussion between the RIPE NCC engineers and community engineers. And we all sort of prone to solutioneering and have our own particular views on how things should be done.
.
And I want to really appeal to everyone to frame there in terms of requirements rather than solutions. Think of what our community thinks are the requirements on the core services of the NCC in this context and when we are moving from in‑house to a Cloud solution or to a hybrid solution and things like that. So let's talk about requirements rather than about solutions. And let's also, and this is the perfect transition to the GM, let's also think about the costs that these requirements brings.
.
That's all I want to say. Thank you.
KAVEH RANJBAR: If I may quickly react to that. Thank you, Daniel. Of course, fully agreed. I think it's important to actually frame the discussion because this is not about Cloud or not Cloud. Right. This is about long‑term operations of RIPE NCC and also not only today or next year, in three, five, ten years, let's say, how we can provide the best service, most reliable and of course cost effective, but it's not about money, this is about being able to sustain correct because of course if operations become so expensive, if we are all on premises and we will need to pay hundreds of thousands for transit just because we need to be able to mitigate whatever traffic that we get. Of course that is not sustainable. So we want to make sure that we provide a service to you, which is reliable and the organisation is sustainable. I think that's the right framing and of course using Cloud then is one of the solution to say mitigate that problem. But there might be other ideas and we would look to discuss that.
.
That's one. And second, maybe a bit of background about how we went there, because clawed was not something coming from RIPE NCC to the management to the staff. We saw that ‑‑ actually some of engineers were really enthusastic about that, so we saw it came came a bit from engineers and we saw that some of our service providers are mandating us or telling us we want provider services and they are migrating to the Cloud and we said okay let's start discussing. So it was really to be honest, it was bottom‑up. So and then of course we had a good am in of engineers against that for many of the reasons which were shared also in this session or on the mailing list internally we also see that, it's not like none of our staff are worried about US for example, or a possible political issues thing like that. What we got from all of them was we started a discussion, right, and including all of those ideas, we started engaging with the community and as I have mentioned, I guess to keep engaging. In the organisation now we have a good number of engineers supporting what we do, but of course constantly we get feedback also internal from the community and, as I have mentioned, it is my job, I see it as specificating the consensus to get all the input from all of the community, the membership, and of course the other aspects, legal, financial, and/or engineers team, considering the long term sustainability of the RIPE NCC, make best use of the opportunity. That's all. So it's really not about Cloud or not Cloud. It's about how we sustain to get it.
KURTIS LINDQVIST: We have the GM in five minutes. I want to thank you very much for this presentation and a discussion. We have two brief things left in the agenda. One is that we, as the Working Group Chairs, just wanted to encourage anyone who wants to run for the Working Group Chair selection at the next RIPE meeting, please consider this so that we ‑‑ as opposed to last time when we had no other candidates we could actually have some selection.
.
And the last thing was the open microphone. I really hope there is no questions for the open microphone. I want to just press the debate but I don't see anything coming up now, and with that I declare us done. And we are now all moving over to the RIPE General Meeting which you should have received a link for and I will see you all over there. So thank you very much for this and look forward to seeing you personally next time.
.
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
