Skip to main content

Interim Session 6 September 2021

Monday 6 September, 16:00–18:00 (UTC+2)
Chairs: Rob Evans, Bijal Sanghani, Kurt Erik Lindqvist,
Scribe: Karla Liddle-White
Status: Draft

RIPE NCC and the Cloud Requirements and Principles

Summary: Rob Evans, RIPE NCC Services WG Co-Chair, opened the session and introduced Felipe Victolla Silveira, RIPE NCC Chief Operations Officer. Felipe began with a presentation which covered the principles and outlined changes to the draft cloud strategy. Rob then opened the floor for questions and comments from the community.

Presentation slides

Randy Bush referred to slide 15 and asked if there were interdependencies between different services. He asked whether RPKI relied on the RIPE Database and if so, would they then have a similar criticality and what the reliability interdependence was.

Felipe said that RPKI relied on the RIPE Registry software, not for the repositories but the core, and the software would have a high criticality level. Based on the architecture they used, it would not affect the repositories – only the ability to make updates to the Certificate Authority.

Randy said it depended on how it went down. The Internet would not be severely damaged if it couldn’t reach a publication server for an hour – but if it got bad data then there was a problem, so there was a quality issue.

Felipe said it should be fine even if there was downtime for the repositories, but they would have to rely on good implementation. Considering the integrity of the trust anchor, failure was not an option and that was a big area of focus for them.

Rüdiger Volk said it wouldn’t be appropriate to state that RPKI was a single service with uniform requirements over all its parts and applying the principles to all the parts of the architecture seemed questionable. When you looked at certain services, you had to look at its different parts and the architecture providing it. 

Felipe replied that requirements would differ depending on whether they were talking about the repositories or the core and trust anchor. They would not go for a fully distributed architecture for the core. The focus for the trust anchor would be on integrity, so the data didn’t get corrupted and wrong certificates issued. For the repositories, it was about reachability and low latency – and internally they did have that distinction.

Rob asked what progress had been made over the past six weeks.

Felipe said it had been holiday season, so people had taken time off to rest. They had been watching the mailing list and responding to messages. Now they were making sure that what they provided to the Board incorporated the feedback they had received.

Rob said the presentation was very interesting – there were conversations happening at his employer about which services they continued to host in house and which to put into public clouds. The framework they had published could be useful for other people as well.

Niall Murphy asked whether the presentation addressed the US-orientation of the major cloud providers.

Felipe responded that one of the principles they had developed was to buy locally where possible, and to look at European cloud providers and others within the RIPE NCC’s service region. There were some options, but these were not at the same level of maturity as the US ones. It was a goal to prioritise providers within their service region.

Rob said the offerings from the US providers were a lot more mature. He asked how this would be weighed against the smaller and (possibly less mature) product sets from EU providers.

Felipe said this would depend on the requirements for each service. For example, with RPKI there were lots of options, but if they were going to use a lot of managed services then that was where the big US providers would have an edge. This would depend on their requirements and they would look at this on a case-by-case basis.

Randy said Amazon and Azure were very heavily-developed shiny objects that locked people in with their services. If the RIPE NCC stuck with its criterion of portability and being able to switch providers, they would find the European providers quite reasonable.

Felipe agreed that if they didn’t use the specific managed services then they could stick to the basics. He added that to minimise vendor lock-in they would only use bare-metal, VMs or containers – and not tough the managed services. He asked what people thought about adding containers.

Randy said that he didn’t see how they could do this without containers.

Niall added that containers were fine, but they shouldn’t forget data - one of the central aspects of lock-in was about data transmission. 

Daniel Karrenberg, RIPE NCC, said the next steps were to discuss RPKI and the RIPE Database in the respective working groups. He encouraged people to join in these discussions. He added that there was also the categorisation of services in terms of their criticality, and that they would like community participation here as well. He added that this was not the final step in this endeavour but the start. He added that it would be helpful for people who thought this way of conversing the RIPE community worked to say so at the RIPE Meeting. This was a lot of work for RIPE NCC staff; having positive feedback would go a long way to motivate people to continue.

Randy said he supported the process, though he found it too theoretical. He added that he would like to hear about experiments being conducted and the practical elements coming through.

Rob thanked Felipe for his presentation and thanked attendees for their feedback.

End of session.