You're viewing an archived page. It is no longer being updated.
Routing Working Group Draft Minutes - RIPE 69
Thursday, 6 November 2014, 14:00-17:30
Working Group co-Chairs: João Damas, Rob Evans
Scribe: Alex Band, Fergal Cunningham
João Damas, Working Group co-Chair, opened the meeting, thanking the stenographer, scribes and chat monitors. He invited comments about the Routing Working Group minutes from RIPE 68 – there were none, and the minutes were marked as final.
The presentation is available here.
Gert Doering (Spacenet) sais that he is not sorry for starting this process 12 years ago because it was a starting point for discussions that needed to happen. He hoped that some BCOP group would pick it up. Currently the recommendation is to accept what is stated in the IRR. The discussion that was had in the Routing Working Group a couple of years ago never came to a solid recommendation because we didn't have the experience at the time. All in all, deaggregation is not necessarily bad, especially in the case of BGP-based multihoming. So really, the question is not just 'do we permit deaggregation', but also if we want to offer up a slot in the global routing table. This also depends on the willingness of operators to implement IPv4 and IPv6 differently.
Geoff Huston (APNIC) said he doesn't understand what the problem is you are solving because he doesn't think the size of the routing table is an issue. The global routing table is relatively tiny, because when you start looking at large enterprises the internal routes enter into the millions. He thinks IPv6 is starting to look a whole lot like IPv4; around 30% of the IPv6 routes are currently more specific and he expects it to grow to 50%, just like IPv4. Because ultimately, routing doesn't need rules, it's needs conventions and negotiations.
Rob Evans (JANET) says that as one of the authors of ripe-532, it's clear the operators and market will decide how this situation will evolve. It's fine revising the existing document, but whatever we put in text may change.
Ruediger Volk (DTAG) said that he would like to hear the speaker respond to Geoff's statement. Enno said he merely wanted to start a discussion and that he hopes that the market will make a decision. In short, whoever does strict filtering should consider this policy. In turn, Ruediger said he is a fan of strict filtering, but the question really is where you pull the information from for your filters. Ruediger continued to explain that he looks at the route6 object in the IRR, as well as the prefix length. Specifically, nothing longer than /48 will be accepted.
Tahar Schaa (Cassini) agreed with the speaker's points. He explained that with IPv4, managing routing was easy because they had total control. This becomes a lot more complicated when they don't have their own infrastructure but, for example, lease it from third parties.
The presentation is available here.
Geoff Huston (APNIC) said that about 7% of all routes don't obey the rules that they are formulating. In the detail of routing, in some cases you might end up being each other's customer. You might assume that relationships are homogenous but they are not. In fact, when you compare your model to reality, you might find very different results, which might be because your model is wrong.
Alex (unknown org) asked about the validation of the relationships. He would like to have additional information from the speaker, because he is very surprised this is done by CAIDA. Benno explained it is all formulated in the paper.
Paolo Lucente (Cisco) said that he working on a draft in the IETF that is very much related to this topic, but it takes a different approach. Instead of building a database, you advocate what to do in case you spot a route leak; for example how to detect and not to block.
The presentation is available here.
Jen Linkova (Google) asked how many private ASNs have an invalid origin AS. Daniele responded that he did check that, and it's very few; about 1-2%.
Tore Anderson (Redpill Linpro) said that as an operator who has been considering dropping invalids, he would like to know which routes would be truly unreachable. He would like to know where they are, for example whether they are bunched up in the LACNIC region or spread evenly. Daniele responded that he doesn't have detailed data about that. What he does see is that operators create ROAs for a specific AS, but they originate it from another one which is very similar.
Ruediger Volk (DTAG) thanked Daniele for suggesting that everyone should create ROAs. More specifically, make sure you register the right ROA.
Sebastian Wiesinger (Noris Network) wanted to know if anyone has contacted the operators who have created incorrect ROAs. Daniele says that he hasn't done that yet.
The presentation is available here.
There were no questions for João and Rob.
The presentation on ExaBGP, which is an application to allow network route injection or route connection on your server, is available here.
Thomas King (DE-CIX) asked about using ExaBGP to set up a route server. The presenter says there are a number of features missing before this would be possible, including a client to ask the state of every BGP session. He says what is also needed, apart from what is in ExaBGP, is local fibre manipulation that is storing the routes in a database. He says this is something he hopes to come back to once he has met other commitments.
Thomas King said he would be willing to work on this and Thomas Mangin said he is always willing to work with people who want to develop ExaBGP.
Sebastien Wiesinger (Noris Network) said he uses and likes ExaBGP but he would like to see comprehensive documentation.
Thomas said he realises that this is a weakness of the software but he points out that there is a folder on the site with a lot of self-testing code that could be useful.
David Freedman (Claranet) praised Thomas's commitment to the code base. He related an instance when his route tester failed and they decided to use ExaBGP but had problems scaling it. He says Thomas came to his office and removed checks in the code that allowed ExaBGP to outperform the route tester, and this demonstrates Thomas's commitment and dedication.
Alberto thanked the RIPE Academic Cooperation Initiative (RACI) for allowing him to attend and present.
The Presentation is available here.
Sander Steffann (S.J.M. Steffann) disagreed that scalability was not an issue any more, noting that governments in some cases were planning to deaggregate large portions of IPv6 address space. He also said that he was worried about feature creep with LISP, as it was developed after the RFC was written.
Alberto agreed and said that routing scalability was a use case for LISP.
The presentation is available here.
Gert Doering (IPv6 hacker) said that trying to include every routing protocol in Homenet could reduce its operability, and he asked if this was something that should be pursued.
Martin said the source destination routing could be used outside of the Homenet and he asked why not have this extension in as many routing protocols as possible. He added that when one OpenWRT box runs Babel and the only network existing runs IS-IS, the whole network will switch over to Babel. He said this was another discussion that needed to take place.
Sander Steffann (S.J.M. Steffann) agreed that Homenet needs to be plug and play.
Martin said that yes, Homenet just needs to work for most people, but there is a discussion on how it should work in the Homenet Working Group and he hopes people will join that discussion and make their opinion heard.
Matthew Moyle-Croft (Amazon) said there needs to be a good example piece of code to run as a default or else there will be a terrible CPE.
Martin said that the discussion was taking place at the IETF and that's where the feedback should go. Joao asked Martin to take the feedback received, especially regarding the CPE, at this session and relay it to the IETF because many attendees would not make the IETF.
George Michaelson (APNIC but speaking in a personal capacity) raised the problem statement of what happens when cross-registry checks are not carried out across the RIR databases. He discussed cross-registry routing authorisation issues, where for instance address space can be registered in one RIR region and the upstream AS Number can be registered in another region. He said this causes few problems for the RIPE region but causes problems for the other regions and can lead to hijacking of non-RIPE address space within the RIPE region. He explained the problem in some detail and suggested using some RPKI while allowing RPSL to continue to do what it does well to help remedy the situation.
Joao said that there would always be problems if you need more than one entity to agree on anything.
Elvis Velea (V4Escrow) said that George's idea was a good one and that no one should be allowed to create route objects for address space they don't hold. He said there was no answer to the second problem of what should be done when hijacking takes place. He said the RIPE Database would allow someone in RIPE to enter address space from a different RIR and it would let him do so. He asked if the RIPE NCC should take steps against those who carry out hijacking.
Joao said that the RIPE NCC was not the Internet police and should not be. He said the introduction of restrictions in the IRR would be a better solution. He asked the attendees if the RIPE NCC should look into the implications of changing the RIPE Database behaviours to deal with these issues and there was agreement that it should.
Shane Kerr (Dyn) said he hoped there would be no more efforts to look at RPSL cross-registry authentication, and Joao confirmed this did not work in the past and would not be tried again.
There was a comment that this issue was becoming very public and to avoid it becoming a known method of hijacking it should be dealt with quickly. Joao agreed with this.
Rob Evans said there were a number of requests at the BCOP Task Force for knowledgeable routing people to contribute, and he asked people to look at the slides from that task force and contribute to discussions.
Alexander Azimov gave a presentation on route leaks called “Everybody Leaks”. The presentation is available here.
There were no questions.