RIPE 87 Routing Working Group Minutes
Thursday, 30 November 2023, 14:00 - 15:30 (UTC+1)
Chairs: Ignas Bagdonas, Ben Cartwright-Cox, Paul Hoogsteder
Scribe: Ed Shryane
Status: Final
View the video archive
View the stenography transcripts
View the chat logs
1. Introduction
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/108-RIPE87-Rome-Routing-WG-slides-v1.2.pdf
Ignas and Paul opened the session and welcomed attendees. The minutes from RIPE 86 were approved.
Paul raised the issue of co-chair selection. He asked whether to have set terms for co-chairs. He reminded that chairs are always selected at the meeting, but discussion on the process can happen on the mailing list. He will send a proposal to the mailing list and invited comments and discussion.
Mirjam Kühne, RIPE Chair, asked to comment on the process during the session. The co-chairs replied that they preferred the discussion to take place on the mailing list
2. Towards 6G and NTN: Opportunities for SRV6 and AI
Marco Paesani and Pietro Cassara (ISTI, CNR)
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/91-20231130_6G_NTN_SRv6_AI_RIPE.pdf
Marco Paesani and Pietro Cassara presented about 5G Non-Terrestrial Networks (NTN) and moving to the 6G era, before doing a deep dive on SRV6 and AI.
They propose a protocol stack in infrastructure involving SRv6 to avoid continuously handover between cells.
Tom Hill, BT, expressed concerns saying first of all, SRv6 is not the future singular. While there are some use cases for it, he was concerned about the narrative that SRv6 is IPv6 and IPv6 is SRv6, which he said was not true. The overheads of SRv6 and the security problems introduced are concerning. He asked to give more thought to a world in which IPv6 is the most important protocol and said that it was important to be clear that SRv6 is not required for IPv6.
Marco Paesani replied that SRv6 offers a good opportunity for growth in the future.
Tom Hill replied that SR MPLS is an exceptionally good protocol, and he was happy that we are still learning and he wants to contribute to it.
Ignas commented that academia and the network operators might see the same aspects in very different ways. He asked if the Routing Working Group mailing list might be a place to continue these discussions.
Tom replied that there is work to be done and there are matters to be raised as these topics are important to operators. There is not enough operator participation in the IETF and a lot of things are developed there and standards are debated. RIPE as a community could expand on the consequences, security considerations and discuss things further.
Berislav Todorovic from Juniper Networks asked if Marco had considered all use cases such as multicast?
Marco replied that he didn’t know about multicast in the future and he hadn’t implemented multicast.
Berislav’s concern was that if you are introducing something, you need to take into account everything that's running today, and multicast is a substantial part of it, and is a means of transporting information over the network from one to many. Any future mechanism will need to mimic this.
Berislav also asked if they had considered migration scenarios from current situations to the new architecture.
Marco replied that he had studied the local network and local provider in Italy, which only use SRv6 and nothing else, and that was sufficient.
Ignas summarised the discussion by saying that there is a level of misalignment in the views that could be rectified.
3. RPKI Repositories at the RIPE NCC: A Deep Dive
Ties de Kock, RIPE NCC
The presentation is available at:
https://ripe87.ripe.net/presentations/111-202311-rpki-repositories.pdf
Ties de Kock presented a short deep dive on RPKI Repositories at the RIPE NCC.
Ties informed the community about usability testing that is in progress on the RPKI dashboard and invited participation by the community.
He then described the initial setup of the RPKI server side infrastructure, which used RRDP with RSYNC as a backup. Unfortunately, the RSYNC backend depended on NFS which cannot cache metadata, and when there was an RRDP outage, it caused an extreme spike of 250K IOPS on NFS when clients had to fall back to RSYNC.
The improved infrastructure is more complex but more resilient.
Ignas invited discussion from the audience but there were no questions.
4. SCION: Secure Path-Aware Internet Architecture Deployment Update
Nicola Rustignoli, SCION Association
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/98-202311-SCION-RIPE87-routingWG.pdf
Nicola Rustignoli presented on SCION which is a path-aware inter-domain routing architecture, including the trust model, deployment model, community and next steps.
He focused on deployments and on the Internet drafts that they had been working on. SCION’s trust model is based on isolation domains, there is no omnipresent root of trust. Their lighthouse use case is a SCION deployment on the secure Swiss finance network. SCION is also in use in a healthcare network, in the power industry and in education.
Tom Hill, BT, said that he's had his eye on SCION at IETF for a while. He said he was still confused as to why this level of trust needed to be added to routing protocols, he believed it was solved at a higher level of protocol. He also asked if someone were to run SCION, would all their border routers in an AS number need to run SCION and perform SCION activities?
Nicola replied by saying that SCION can run in parallel with an existing network. In principle, there could be one border router and a connection to a SCION neighbour to collect traffic from customers. It doesn’t need to be enabled on all of them.
Tom asked if there was a way to provide SCION over an existing network that is non-SCION compliant?
Nicola replied that interoperability could be improved. Today this is done by running a SCION gateway inside ISPs so traffic is collected as close to the source as possible but limited to a single Autonomous System.
Peter Hessler, OpenBSD, said that in all the examples of deployments shown the groups trust one another. If SCION was used more widely in a more general purpose network in which many groups do not trust one another, how would isolation domains and trust relationships work?
Nicola said that groups that do not mutually trust one another they would perhaps end up in separate isolation domains and communication between the two might be possible by accepting each other’s root certificates. SCION makes this trust or distrust more explicit. Within each isolation domain however, a level of trust is required.
5. Open Microphone Discussion
Ignas invited comments on activities taking place in the Routing Working Group.
Tobias Fiebig, MPI, informed the Working Group that he was working on an IETF draft updating BCP 194 for BGP security considerations. He asked those interested to look up the draft and provide feedback.
Peter Hessler said that he was quite happy for the Working Group not to necessarily publish documents, it’s strength was providing information to operators especially about IETF protocols and discussions.
Ignas said that he was glad to hear that everyone is happy with the Routing WG. He then invited discussion on the chair selection process.
Paul Hoogsteder said that humming was used during the previous Chair election. On the one hand, humming is relatively anonymous but on the other hand, it doesn’t provide a strict count. Someone sitting in the front of the room could have more influence because they are more audible.
Tom Hill said that the IPv6 Working Group had used a Meetecho poll to elect a chair and it worked quite well.
Paul asked if attendees needed to be logged in to vote, and the answer was yes.
Jen Linkova commented that it was possible to use the Meetecho Lite phone client as well and that people are required to register for the meeting in any case. Remote participation is free and it was important to allow people not physically present to participate and vote. Remote participants should not be discriminated against.
Paul also asked for comments on fixed terms and term limits. He asked what people thought about continuity and said that people might not want to lose a hard working Chair over a term limit.
Mirjam Kühne, RIPE Chair, commented that to go a step back, different working groups use different methods. In the past, the term ‘selection’ was used a lot if Working Groups didn’t want to hold an election at the RIPE Meeting and have selections via the mailing lists instead. It was felt that having elections at meetings was unfair as it excluded online participants. However, people also find it awkward to say negative things about colleagues on the mailing lists. Now with Meetecho, it is possible to include remote participants as well. At IETF, Meetecho does allow humming but they said that polls are better with the facilities at RIPE Meetings. It is not a requirement, but some Working Groups like the IPv6 Working Group tried it out and had a good experience. Regarding term limits, across the community, there is a growing ask to have them. It doesn’t mean that Chairs can’t stand again, but having an open call on a regular basis helps people plan and prepare to volunteer. It is healthy to have a certain rotation and to have term limits for Working Group Chairs. It’s also healthy to take a break as a Chair and get new people.
Jen Linkova asked for a clarification on what is meant by term limits – did that mean limiting the number of terms or the duration of the current term.
Mirjam replied that both are possibilities – having term durations and a fixed number of terms allowed, some Working Groups have both. The DNS Working Group has done this for many years. They have term limits after which the Chair has to take a break after two terms and then they can stand again after a break of one term. Some other Working Groups have new Chairs coming in periodically and Chairs that stand down can reapply once but not more. It’s up to the Working Group to decide.
Shane Kerr, IBM, said that he was one of the people who encouraged the DNS Working Group to adopt limits. They have three-year terms and a maximum of two consecutive terms. It’s a good way to have new people in and to provide a gentle way for people to step down if they are losing enthusiasm. If it’s hard to find people who are interested in the topic and able to step up, then perhaps the Working Group isn’t as interesting as people think. He added that his preference was for all Working Groups to have the same procedure and policy and encouraged them to use the DNS Working Group procedure.
Daniel Karrenberg, speaking for himself said that Working Groups risk appearing inaccessible to newer people who are enthusiastic. He encouraged Working Group Chairs and members to look around for potential candidates and be open to change and diversity in age and hair colour.
Peter Hessler offered a concrete proposal. Since the Routing Working Group has three Chairs, he suggested that each Chair get a term of three years, with one Chair up for election each year. He said that he had no specific preference as far as term limits were concerned, two or three terms seemed reasonable. He suggested raffling among the existing Chairs to see who would get a one-year term, a two-year term and so on.
Daniel offered a counter proposal of having two-year terms with a maximum of two terms to have a good churn. He thought that was not thankless towards the Chairs who do a good job but to encourage turnover and provide opportunities for new people.
Paul asked how Daniel’s proposal would work with three Chairs and two year terms. That would require two Chairs to step down in one year and then the third in the next year. He felt that was too quick.
Daniel said three years felt long to him, but his point was to push for more renewal.
Ignas said that an immediate solution was not required and the discussion could continue on the mailing list. By the next meeting, it would be good to have something decided upon both regarding Chairs and envisioning the role of the Routing Working Group. He invited everyone to share their opinions.
He also asked for feedback on the new format where there is more time for discussion compared to back-to-back presentations and that if the Working Group was pleased with it, they might try to continue this at the next RIPE Meeting.
Mirjam pointed out the possibility of holding interim sessions if there is too much content to address during a RIPE Meeting session. The RIPE NCC is happy to assist with this in between RIPE Meetings.
Paul concluded the session by thanking everyone present and inviting them to join in the next RIPE Meeting taking place in Krakow.