RIPE 54

• content to the Chair of the working group.

format to webmaster@ripe.net.

WG: Routing
Meeting: RIPE 54, Tallinn
Date-1: Thursday, 10 May 2007
Time-1: 14:00 - 15:30 (UTC +0100)
Chair-1: Joao Damas, Rob Evans, Joachim Schmitz
Minutes-1: Alex Band
Jabber: xmpp:routing@conference.ripe.net
J-Scribe-1: Brett Carr
J-Script-1:
Audio-1:
WG URL: http://www.ripe.net/ripe/wg/routing/
Material: http://www.ripe.net/ripe/meetings/ripe-54/presentations/
Agenda: http://www.ripe.net/ripe/meetings/ripe-54/agendas/routing.html
--------------------------------------------------------

A) Administrivia

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

--------------------------------------------------------

B) Router FIB Scalability (John Scudder, Juniper)
http://www.ripe.net/ripe/meetings/ripe-54/presentations/Router_Scaling_Trends.pdf

Question: Randy Bush (IIJ) asked why it is necessary to take the more specific into the RIB when you can compress it out of the FIB.

Answer: If the covering aggregate goes away, you need the route in the RIB because it is going to end up in the FIB. And as routes move through the Internet, at some point further back along the packet flow, the next hop of the aggregate and the more specific may be pointing in different directions. At that point you can't compress them because they say different things.

Randy argues there is a significant amount of /24s sitting around for someone de-aggregating intentionally because they think that gives them security. John responded that nothing can be done to prevent that from happening.

Randy said that you can currently scale routers to handle two million routes. He feared that with IPv6 on the horizon, we are going to see /29s and /30s with NAT behind every one. This way, we will end up with ten million routes. John replied that currently you can buy a router that can handle two million routes and there is technological runway to scale routers to handle ten million routes.

Question: Randy Bush asked if the BGP free core, a.k.a. the Internet free core, used routing or whether it is circuit based.

Answer: It is tunnel based, for example an MPLS tunnel, but it doesn't have to be.

Question: Lorenzo Colitti (Google) asked if there are unpleasant surprises on the horizon once IPv6 is deployed.

Answer: No, because in the end, IPv6 is IPv4 with 96 more bits. They know how it's going to scale and perform in the control plan.

Question: Christian Vogt (Ericsson) asked if the BGP churn (the recomputation rate of the routing table) be supported by routers in the future.

Answer: John deferred the question to David Ward, since his presentation is about this topic.

--------------------------------------------------------

C) Modest Improvements to BGP (David Ward, Cisco Systems)
http://www.ripe.net/ripe/meetings/ripe-54/presentations/Moderate_BGP.pdf

Randy Bush (IIJ) expressed his concern about the differences in MinRouteAdvertisementInterval (MRAIs). The imbalances can create "surprising emergent behaviors", as the term was coined.

Dave responded that the amplification effect possible in the protocol is certainly something that needs to be addressed. The topic is also understudied.

Randy said that some vendors have implemented the TCP stack for BGP in such a way that the peer was expected to be very close. When researchers used route views when most of the measurements were multihop eBPG, they got false results.

Dave replied that when taking a closer look at the routing data - regardless of any vendor affiliation - the actual implementation of TCP and BGP is critical to observe: of the collector itself and of what's peering. The implementation affects the data as it's being collected, so you need to have an understanding of it when interpreting the results.

Question: Christian Vogt (Ericsson) asked if route convergence will not be a problem ten years from now, if we continue on the current path.

Dave replied that for iBGP sessions today, route convergence will not be an issue, since BPG is relying on IGP for it's next hop. eBGP convergence, when using alternate paths techniques, can also be very low. It doesn't make a difference if you use IPv4 or IPv6. If the implementation stays the same, there won't be any problems ten years from now. What will remain the same is initial BGP convergence, you have to have specific deployment considerations to be able to handle BGP startup.

Dave posed the question to the group: is this an issue that should be resolved or can it be handled in deployment.

Comment: John Scudder (Juniper Networks) added that we shouldn't be worried that BGP is just going to stop working at some point, but it's always worth improving convergence.

--------------------------------------------------------

D) Diagnosing the Location of Bogon Filters (Randy Bush, IIJ)
http://www.ripe.net/ripe/meetings/ripe-54/presentations/Bogons.pdf

Question: Leo Vegoda (IANA) asked if the problems with Bogon filtering are going to go away in two years time after the last /8 has been allocated.

Answer: Randy replied that we will have the same problems with IPv6 once that is deployed ten years from now.

Ruediger Volk (Deutsche Telekom) commented that ISPs and networks who just do Bogon filtering will have a lot of trouble with hijacked announcements. What he would like to see in the networks is positive filtering, which would be link specific.

Erik Romijn (RIPE NCC) mentioned that the RIPE NCC has a similar project for the Routing Information System (RIS, the Debogonising Project, but they currently only look at BGP data. He would like to know if there are many cases where the traffic is actually filtered but it's not filtered in BGP.

Randy replied that BGP policy hides information, so it is essentially useless for research. Even from RIS data, you get a fraction of the information that is actually out there. Most of the filters they are hitting are BGP announcements filters, but three hops away, there is no way to tell.

--------------------------------------------------------

Z) Wrap-up & AOB

Joao Damas mentioned that the Address Policy WG is asking for input on policies that have incidents in routing.

Gert Doering (Address Policy WG Chair) clarified that there seems to be a consensus that Address Policy documents should not contain routing recommendations. On the other hand, people who get address space from the RIPE NCC need some guidance as to what the expected behavior of that space should be. Since the Address Policy WG may not be so qualified to give routing recommendations, perhaps the Routing WG can create a recommendations document to which the Address Policy documents can point.

Randy Bush argued that Routing policy is not easily done by committee. There was some discussion over the changeability of policy.

--------------------------------------------------------

Action Points:

There were no actions points.