RIPE 55

• content to the Chair of the working group.
• format to webmaster@ripe.net.

Thursday 25 October 2007 14:00 - 15:30 (UTC +0100)

Chair: Joao Damas, Rob Evans, Joachim Schmitz.
Minutes: Alex Band (RIPE NCC)
Jabber Scribe: Arno Meulenkamp (RIPE NCC)

A. Administrative Matters

There were no open action points that required attention. There was no input on the minutes from the last meeting on the mailing list.

B. RIS Update - Erik Romijn, RIPE NCC

http://www.ripe.net/ripe/meetings/ripe-55/presentations/romijn-ris-updates.pdf

Erik asked the room how many have used RIS. About two thirds of the room had.

Dave Meyer (Routeviews) asked if RIPE NCC has had any requests for real-time access, and if so, what kind of plans IS would have around that.

Erik replied that in some cases, they were asked to provide a full table from one of the collectors. However, there is no streaming system that sends everything that RIS sees and there has been no request for that.

C. Implementing a Bogon Filter Detection Service - Steve Uhlig

http://www.ripe.net/ripe/meetings/ripe-55/presentations/uhlig-bogon-filter.pdf

Bernard Tuy (RENATER) asked if the idea is to tell ISPs not to filter bogons. Steve confirmed and said they found out that reachability is hard to check. The goal is to refine the methodology, and not use brute force probes. The goal is to find who the culprits are, in order to fix the problem faster. Bernard said he was not convinced that ISPs will want to disable bogon filtering. He asked through what mechanism it is announced to the community (i.e. ISPs) that a new prefix is not a bogon. Steve said it is not up to them to answer that question.

Andrei Robachevsky (RIPE NCC) commented that, in Erik's presentation, the goal is to analyze prefixes which is it expected may be filtered as a bogon by the ISPs. It allows ISPs to check their own reachability. If someone is filtering a prefix on the way, so not necessarily by them, it is very hard to pinpoint where that is happening.

He continued that before the allocation of newly received /8s starts, certain prefixes in the BGP are placed, and allow people to check if they can reach them. There is reporting built in, but doesn't allow pinpointing of where a prefix is filtered. Andrei continued that the RIPE NCC is working on a very small subset of all ASs, which may not even be statistically representative.

Andrei asked if the figures that the Debogonising Project reports, and the figures that Steve got with his experiment match together in any way.

Steve commented that the speed at which bogons get fixed over time is matched. Most prefixes get fixed pretty fast, but some keep being filtered for weeks, or even months.

Joao commented that the reachability of prefixes may become more problematic as allocation from more 'exotic' blocks begins

Ruediger Volk (Deutsche Telekom) noted that some debogonising announcements had no IRR registered root, which means that people who have white listing filters would show up as 'bad guys'. Also, as far as debogonising goes: we will only have to deal with another 40 cases for IPv4.

Ruediger asked if Steve's technique also works for people who use white listing filters. Steve responded that he thought it would work.

An attendee asked how this will work in IPv6.

Steve said there would probably be even more bogons. However, the scale will be bigger, but the methodology will be the same.

Joao asked what this system would look like if it were to be set up as a service. The Routing WG would like to have a report presented in the RIPE NCC Services WG.

D. BGP Update Damping - Geoff Huston, APNIC

http://www.ripe.net/ripe/meetings/ripe-55/presentations/huston-damping-update.pdf

Paul Jakma (Quagga) asked if mechanisms like AS-PathLimit (Tony Li, et al) might help alleviate the update-load from traffic engineering.

Geoff replied that he doesn't think AS-PathLimit is relevant to this particular problem. He added that he thought what Paul was contemplating is the idea of limited propagation, which means that you want the advertisement to go only so far and not further.

Geoff said he is not looking at that, but rather at the update load, not the prefix size. He concluded that it appears that a lot of BGP updates can be removed because most of them are actually an artifact of withdrawls.

Lorenzo Colliti (Google) asked if Geoff has thought about the effects of not telling your peers what's happening.

Geoff explained that there is a lot more to do than just looking at the suppression of just one router. The next step is to look at it in the context of a network.

Geoff went on to say that all he has done is taking the two clues clues that we have used so far: 1) this extends the MRAI timer, because it already put the 30 second interval on this (in other words, it suppresses activity on the prefix). And 2) taking the technique of output queue compression, and supplying it selectively on prefixes that appear to be having growing AS path length, which is a strong clue of withdrawls coming. Essentially, there is no point in sending the intermediates. The next step (hints to Paul Jakma) is to deploy it in an actual system. Paul Jakma (Quagga) later says Geoff can log an RFE.

Tiziana Refice (RIPE NCC) asked if convergence time has been measured. Geoff replied that this algorithm doesn't damp the withdrawl. So if it's convergence to withdrawl: it's the same time. So far, Geoff hasn't seen a downside.

Roque Gagliano (ANTEL) asked if the system is going to hard coded, or whether there is some sort of standardisation needed.

Geoff responded that he believes that the MRAI timer does not need standardisation, because it's not the timer itself that is causing these issues. He believes that most implementations haven't been done absolutely correctly: instead of doing a 30 second gap between successive updates for the same prefix, they apply 30 second timer on all updates to the same peer.

Vince Fuller (Cisco Systems) asked if Geoff verified whether the cases where the path length is longer, is a truly path hunting artifact and wasn't just a backup path, which just happens to be a longer AS path. Geoff responded that he is looking at that, as well as many other details.

E. A Beginner's Guide to LISP - Vince Fuller & Dave Meyer

http://www.ripe.net/ripe/meetings/ripe-55/presentations/meyer-lisp.pdf

F. Locator/ID Split Transition Issues - Darrel Lewis

http://www.ripe.net/ripe/meetings/ripe-55/presentations/lewis-lisp-issues.pdf

Christian Vogt (Ericsson), referring to slide 3, commented that the main function of LISP is to have a scalable way of proving Provider Independent (PI) address space to the edge networks. Keeping this in mind, the first approach is something that you don't want to do. If you left the edge pointers in the global routing table, then you really don't increase availability, but rather the opposite.

Christian said he preferred the second method. The proxy tunnel router approach is essentially the same as the routable EID space if you have a single proxy tunnel router that advertises the address space. It becomes more scalable if you group proxy tunnel routers from multiple providers together and have all of them advertise the same addressing space in a single block. He continued that the question Chistian has is that this would change todays business model, because you require multiple providers to coordinate quite closely. Essentially, you are grouping providers, as well as edge networks together. Regarding the third approach: that would work, although you wouldn't be able to reverse the NATting any longer. The bottom line, according to Christian, is transition.

Darrel commened that LISP can use PA space for EID, it doesn't require PI. Darrel suggested to talk more offline about the grouping of providers and edge networks.

Dave Mayer (Routeviews) responded to Christian concerning the routable EIDs. He said that if they are routable in a scope larger than the site, this means you can no longer renumber that site very easily.

Gert Doering (SpaceNet AG) comments that he has had many cases of lost packets or packets with high latency. He would like be able to easily pinpoint the source of the problem, so he could contact the provider causing it. He urged people working on LISP to give this some thought.

Christian Vogt (Ericsson) commented to Dave concerning the routable end point identifiers. Solutions like SHIM6 make it hard to renumber when you change providers, but there is something in between. He continued that If you take the 6.1 proposal, then it needs renumbering, but in a very easy way. It also doesn't have so many transition issues.

G. The Problems With Using "asdot" to Represent 4-byte ASNs - Joao Damas & Paul Jakma

http://www.ripe.net/ripe/meetings/ripe-55/presentations/jakma-critical-considerations.pdf

Henk Uiterwaal (RIPE NCC) commented that 4-byte ASNs are not a big issue. He said that so far, there haven't been any reports of anything breaking; it's just a dot.

Paul Jakma (Quagga) commented that the idea behind this is to get guidance from the community on whether backwards compatibility either doesn't matter, or matters enough to have RIPE NCC change things. This is what should be given feedback on.

Shane Kerr (ISC) said that the breakage because of asdot is a good thing. This forces people who work with the tools to see they are 32-Bit AS compatible.

Ruediger Volk (Deutsche Telekom) contradicted Shane and to some degree Henk. Generally, the BGP part of 32-Bit AS is done very well. However, actually carrying through all of the required additional protocol support has been really bad, for example the upgrading of RPSL. IRRToolset also fails in some cases.

Jos Boumans (RIPE NCC) commented that RIPE NCC have handed out less than two dozen 32-Bit AS Numbers. Quagga fully supports asdot, and to his knowledge IRRToolset doesn't.

Gert Doering (SpaceNet AG) explained that the whole point of implementing AS3.3 was to see what breaks, so it can be fixed in time. This way, Cisco could be contacted to tell them that their box couldn't be configured. Gert also wanted to raise his hand to say that he is in the asdot camp, because he envisioned that we will not see more than 200.000 BGP AS'es so it will be easy to see which registry allocated an ASN from the digits before dot.

Y. I/O With Other Working Groups

Z. A.O.B.