RIPE 74

Thursday, 11 May 2017, 9:00-10:30
WG Chairs: Joao Damas, Paolo Moroni
Scribe: Anand Buddhev
Status: Draft

A. Administrative Matters

Joao opened the session, introduced the scribe and chat monitor, and approved the minutes of the RIPE 73 session.

B. IRR Filtering at IXP Route Servers - Erik Bais

The presentation is available at:
https://ripe74.ripe.net/presentations/123-RIPE74-Routing-WG-preso-V2.pdf

Wolfgang Tremmel (DECIX) said that if anyone detects hijacking on BGP sessions, they should gather evidence and report it. He said that DECIX needs evidence, and cannot act on hearsay.

Rudiger Volk (Deutsche Telekom) suggested that if anyone does ingress filtering, they should send a report to the sender about what is being dropped, and if possible, with a reason about which policies are causing prefixes to be dropped. This would help senders with bugs in their configuration. He also suggested to first publish the criteria for what will be filtered, before implementing it. Erik agreed that this was a good suggestion,

Randy Bush (IIJ) said he disagreed with one of the criteria for filtering, namely "prefix limit". He explained that in many parts of the world, there is a lot of deaggregation.

Marco d'Itri (Seeweb) agreed completely with proposal. He said he used to report leaks at Italian ISPs but it did not help. He also commented that spamhouse did not list DECIX mail servers; he said that the listing is for a /32 but reported as a prefix for information.

C. Route Leaks - Alexander Azimov

The presentation is available at:
https://ripe74.ripe.net/presentations/136-RIPE74.routing-wg.azimov.pdf

Randy Bush (IIJ) said he strongly supported using attributes instead of communities because communities are often stripped or ignored.

Geoff Huston (APNIC) said that this proposal is trying to solve an age-old problem in BGP. He explained that there have been proposals in the past, and they haven't worked. He said if this is going to work, then let's give it a try, and jokingly asked for assurance that this proposal will work.

Randy Bush said that if one has two separate relationships with a peer then one should set up two sessions.

Geoff Huston said that close to the route leak, one can use the OPEN attribute to reject the prefix. However, with an eBGP session, that is much more difficult, because by the time a prefix is received, some of the attributes may be lost, and one has to go back to marking routes.

D. MANRS Update - Ben Maddison

The presentation is available at:
https://ripe74.ripe.net/presentations/128-201705-MANRS-update-RIPE74.pdf

Randy Bush (IIJ) said that this sounds like a membership club rather than about routing. He asked Ben to show a chart of membership versus bad routing events. He said that bad routing events were increasing, and said there seemed to be a disconnect.

Joao Damas (co-chair) asked the question "what does victory look like?".

Ben said that it's hard to come by information about bad routing events, because it's hard to discover. The source of bad events are not the same as the ASes that have signed up to MANRS. He explained that he didn't know how to determine the point where bad routing events were reducing in comparison to ASes joining MANRS.

Randy replied that big names are part of MANRS and still did bad routing. He thinks MANRS isn't helping.

Joao said bad things will continue to happen, but that we must attempt to do something about it. Randy replied that MANRS was a marketing tool without any technical value.

Ben said that MANRS is a baseline of guidelines, that any network should be adhering to. He said he cared about the fact that there was a group of people concerned with bad routing and thinking about it, and doing something about it.

Rudiger Volk agreed with Randy that this is mere marketing. He said that a clearer technical solution should be defined. He said that clear words about actual technical solutions such as RPKI should be in MANRS. Ben said that the BCOP document already had such text.

Geoff Huston said one shouldn't mistake motion for progress. He said that MANRS is motion, rather than progress. Ben agrees that things have flattened out a bit. He thinks that it would be good if MANRS would progress into an engineering forum where minimum engineering practices could be defined.

Leslie Daigle (Thinking Cat Enterprises) said that they shouldn't lose sight of the community-building aspect of this. She said that when engineering solutions are in fact agreed upon, MANRS could play an important role in fostering the community to actually get these technical solutions out there.

E. BGP Table Fragmentation - Julien Gamba

The presentation is available at:
https://ripe74.ripe.net/presentations/135-bgp-table-fragmentation-what-who.pdf

Thomas Schmidt (DFN-Verein) suggested that one possible reason for deaggregation could be RPKI. Julien said that he hadn't looked into it.

Rudiger Volk (Deutsche Telekom) said he didn't understand Thomas.

Geoff Huston said he had never understood what the issue with scaling is. Is it size of the tables, or rate of updates? He asked whether there was any correlation between size of prefixes and update rate? Julien said they hadn't seen any clear difference amongst the various classes of prefixes.

Randy Bush (IIJ) reinforced Julien's statement by saying that they had measured it, and while the result was not zero, it didn't show any interesting result.

Rudiger Volk asked whether deaggregation was localised to certain regions.

Julien said that there was more deaggregation in the APNIC and AFRINIC regions. Rudiger added that he had seen differences between regions. He gave the example where regions with scarce connectivity may play more routing tricks to make efficient use of bandwidth than regions with plentiful bandwidth.

Francois Devienne (Border 6) thanked Julien for the presentation. He suggested that deaggregation is probably caused by end users wanting to do inbound load balancing, and that we need better tools to help configure this.

Nick Holt (Microsoft) asked whether Julien had done any research in IPv6.

Julien said they looked at IPv6, but there isn't much data about it.

An unidentifiable audience speaker asked whether the study had looked only at the prefixes, or whether the attributes had also been considered. Julien replied that when considering aggregation, they had looked at the AS path as well as BGP attributes. The speaker then asked whether the raw data was
available. Julien said the data was available, and that he planned to release his code as well.

Geoff Huston quoted a study from 2004 to say that more specific prefixes were four times more likely to have updates compared to aggregated prefixes. In other words, more specific prefixes are noisier.

Z. AOB

There were no AOBs.