You're viewing an archived page. It is no longer being updated.
Routing Working Group - RIPE 66
Thursday, 16 May 2013, 14:00-15:30
WG co-Chairs: Joao Damas, Rob Evans
Scribe: Alex Band
Joao Damas, WG co-Chair, thanked the scribe, chat monitor and stenographer.
The presentation is available at:
https://ripe66.ripe.net/presentations/301-RIPE66-Dublin-Route-Object-Process-Improvement.pdf
Alex Band (RIPE NCC) commented that automatic ROA creation based on route objects would be a bad idea. George Michaelson pointed out that the slide was wrong and it was meant the other way around. In addition, Alex pointed out that currently the IRR and RPKI are two completely different data sets that need to be maintained in two different places, even though the statements overlap in intent. George agreed that this is not good and should be addressed. Lastly, Alex commented that, so far, the discussion has revolved around entering data into the systems, and that looking at ways of actually using the data that was created through toolsets could also use some more integration.
Randy Bush (Dragon Research Labs) commented that he supports the idea of having ROAs represented as route objects so that they can be used in existing RPSL workflows.
Ruediger Volk (Deutsche Telecom) pointed out that there are slight differences in the way a ROA and route object are represented. He also felt that there is not much point in investing in a dying technology such as RPSL. George Michaelson commented that there is an immediate problem right now that hostmasters at APNIC need to solve, which is the inability to create a proper route object for ASNs and prefix combinations. This has an immediate operational effect on many routers running on the Internet. Ruediger argued that the ability to create a ROA is enough, as the RIR has the tools available to represent that information in RPSL format. George explained that a problem arises when a route object needs to be created for an ASN or prefix that is not authoritative in the APNIC whois.
Gert Doering (Spacenet) commented that he sees a problem with opening up route object creation without limitations, because certain configurations can overflow the memory capabilities of routers. Gert continued by pointing out that any upstream should be capable of getting a correct route object published with in 72 hours. If they can't, then perhaps it's time to look for another one. George argued that usability at the RIR level is still a factor that he likes to take into account.
Wilfried Woeber (UniVIE) said that he was not aware of the presented problem before this meeting. He continued by stressing the human aspect, there is a requirement for people to take action within a certain amount of time because workflows within organisations may be quite complex. Specific time constraints may undermine the usage of the offered service.
Vesna Manojlovic (RIPE NCC) asked the people in the room for feedback on the idea of adding functionality to RIPEstat that would offer additional Routing consistency information, by adding ROAs to the data set.
Randy Bush (IIJ) mentioned that he appreciates that parties such as ISOC and APNIC want to help him run his network, but he prefers to do it himself.
The presentation is available at:
https://ripe66.ripe.net/presentations/232-SR_RIPE_v2.pdf
Gert Doering (Spacenet) said that he really likes what was being presented and he would like to have it immediately. He continued to ask which vendors are supporting EFT. Christian Martin suggested that all vendors who are contributing to the IETF draft intend to support the technology, which presently are Cisco, Alcatel Lucent and Ericsson.
Jen Linkova (Google) thanked Christian for mentioning their group and presentations at the last RIPE Meeting, as well as at NANOG. Jen asked how the load balancer would work if she has a bundle with a number of links and she tries to construct a tunnel with a stack of identical labels across the path. Christian said that if they are node labels, the load balancer will work like a normal hash works with the local forwarding table. It works no different than a statically configured or LDP label, so it leverages existing ECMP-type behaviour. In addition, in the bundle case you can create an adjacency segment on all data links in the bundle, and you can create them on a group of links. This allows you to do flow-based hashing.
Gregory Cauchie (Bouygues Telecom) said that he likes this idea and wondered what the vendors are planning with regards to multicast traffic. Christian responded that the locus of the idea is to place path state into the topology. The graph that is represented by the IGP gives us the ability to identify every path in the network. So there are only end paths in the network. An intrinsic approach to multicast is much harder to achieve, but because this is an SDN based application, we are working on allowing you to program these segments in a tree format into the topology in the same way that you do in the unicast sense.
The presentation is available at:
https://ripe66.ripe.net/presentations/282-20130515_v2_RIPE66_rNH_gvandeve.pdf
Randy Bush (IIJ) said this methodology allows the signalling path to be non-congruent with the data path, which in his experience is always problematic; it's hard to debug and hard to understand once it gets very rich. In his opinion, there's a real trade-off here and it's very dangerous.
David Freedman (Claranet) asked if Gunter is the only author on the draft. Gunter responded that Randy Bush is an author as well. David continued by asking if this draft has been designed with any practical implementation in mind. Gunter pointed to the use cases that are mentioned in the draft, such as the data centre environment with mobility of VMs, but is it an aspect that they need to put more work into.
Blake Willis (L33 Networks) asked if, given the wide spread adoption by many vendors of RFC 5549, Gunter sees a lot of incentive to get this deployed in a multi-vendor interoperable environment, or whether this is merely a Cisco-specific implementation. Gunter responded that this is being discussed in the IETF with the intent to make it not specific to Cisco.
The presentation is available at:
https://ripe66.ripe.net/presentations/305-20130516_v1_RIPE66_DDoS_Mitigation_gvandeve.pptx
The presentation is available at:
https://ripe66.ripe.net/presentations/275-20130515-v6-darknet.key.pdf
Wilfried Woeber (UnieVIE) asked why the current situation is not useful for Merit, because he had observed that it is already interesting to see that the dark net traffic is not evenly distributed across the /12. Daniel said that Merit's presentation in the Plenary session only shows very rough results and their comment was that there is orders of magnitude less traffic in the /14s that we do allow, making the results less useful than /13s.