You're viewing an archived page. It is no longer being updated.
RIPE 53
RIPE Meeting: |
53 |
Working Group: |
Routing |
Status: |
Final |
Revision Number: |
1 |
- content to the Chair of the working group.
- format to [email protected].
WG: Routing
Meeting: RIPE 53, Amsterdam
Date-1: Wednesday, 4 October 2006
Time-1: 14.00 - 15.40 (UTC +0200)
Chair-1: João Damas
Minutes-1: Erik Romijn
Jabber: xmpp:[email protected]
J-Scribe-1: Vesna Manojlovic
J-Script-1: TBA
Audio-1: TBA
WG URL: http://www.ripe.net/ripe/wg/routing/
Material: http://www.ripe.net/ripe/meetings/ripe-53/presentations/index.html
Agenda: http://www.ripe.net/ripe/meetings/ripe-53/agendas/routing.html
0) Administrative
No changes to the agenda.
1) Recommendations on Route Aggregation - Philip Smith
Philip Smith gave a presentation on Route Aggregation Recommendations. He asked the WG to discuss and approve this document to make it a RIPE Document.
João commented that the WG had adopted the document already as far as he was concerned. There was discussion on the mailing list.
Ruediger Volk commented that he thought router vendors were not responsible for NOPEER and that this has to be done by the network operators. He, along with several others from the IETF Working Groups, does not want solutions where router vendors build more code and deliver more bugs. If you wanted to do it, you would have to implement much higher level policy stuff in the router languages, which you don't.
Phillip replied that he doesn't see it being used anywhere. When people ask him it's "Cisco or Juniper or whoever needs to put something in to say that we can do it". If the text needs to be massaged in any way, he is happy to receive offers.
Iljitsch van Beijnum commented that using more communities and writing more documents is not the way to solve this. These problems exist because people don't do the right thing. The bigger the documents are, the more extensive the options are, the harder people are going to find it to implement them. He thinks it's hard to make these kind of things simple and that we should consider finding ways that make it easy to do things right and hard to do things wrong.
Phillip agreed and does not support more documentation. People tend to look at documentation as a last resort and generally think things should just work.
João agreed and thinks these kind of documents should especially be usable for the clueless.
Iljitsch commented that maybe router vendors could allow users to specify what kind of session a new session is (transit/peering). For simple installations you wouldn't have to manually create all kinds of filters. This is not easy to do because you have to come up with a sane way to make this work and need a good number of router vendors to agree.
João commented that that would mean asking for some kind of macro-language that would be a separate thing. Phillip agreed. João said any more comments should be made to the list.
3) Open Issues with IPv6 Routing and Multihoming - Vince Fuller
Vince Fuller from Cisco Systems gave a presentation on scaling issues with IPv6 routing and multihoming.
Kurtis Lindqvist commented that he was the co-chair of the shim6 working group. He mentioned that in November 2002 there was actually a serious consideration of GSE. One of the concerns brought up was an old draft that did an analysis of the security binding properties between the identifiers and locators. That led to an RFC that has a requirements list of things you're going to have to think of when you want to split locators and identifiers.
There was also an analysis that pointed out what Vince mentioned as perceived security weaknesses. In a review of this document where it is said that this isn't a problem, it is assumed that there is IPSEC between the endpoints during the lifetime of the session.
Vince commented that IPv6 security is not so much worse than IPv4. It is certainly easy to hijack sessions and to spy on sessions with an unsecure identifier and locator binding, but that can be done today with IP as well. He thinks you need to have end-to-end encryption and authentication independent of IPv4, IPv6 or GSE.
Kurtis replied that those issues were not included in the document as it only looked at GSE.
Vince agreed that this is not the right form for an extensive discussion of GSE pros and cons. He does not believe this is an insurmountable issue but it does require more work and research.
Kurtis commented that you would end up with an equal amount of complexity in the end systems as with shim6. There is a proposal to solve this problem. Vince did see the draft but only read the summary. Kurtis thinks that if you want to work out GSE, you'll come up with something very similar to the draft. Vince thinks that it is very likely that he is right and that GSE will require a lot more work.
Kurtis commented that not all 6 million enterprises in the world are willing to pay for the second connection. He noted that there is a cost involved with renumbering, and asked whether that would be higher than the cost for a second connection.
Vince thinks that the Internet will be such a critical utility that businesses will not want to depend on a single connection.
Kurtis commented that multiple connections are not the same thing as multihoming.
Vince's explained that his assumption is that the method of multihoming is going to be the traditional method: getting two connections and having a globally assigned prefix. He mentioned there are multiple options for multihoming and that there are some parts of the world, especially large parts of Asia, where you can't get globally routed prefixes.
Iljitsch commented that that is not true and people can get a globally routed prefix in any reasonable place in the world.
Vince commented that there are some places where people come up with multihoming without a separate globally assigned prefix, that's what his customers tell him, which is partially driven by the difficulty of getting those prefixes.
Kurtis mentioned that in the calculation of the total number of routes, the globally routed prefixes are not the major part of the routes.
Vince explained that his assumption is that you will deploy IPv6 as you have now deployed IPv4 and there are many prefixes internally to infrastructure or customers that are not part of the global table.
Kurtis asked whether it's time to reduce the number of internal routes people need.
Simon Leinen commented that he is not worried, even with these projections. He thinks many people will switch from full routing to partial routing.
Vince replied that he believes that there is still going to be a set of providers that can not do this.
Simon asked how much people can not opt-out.
Vince said he thinks that it is mostly tier-2s that will have this problem. He thinks people can get away with it, but that the trends are not in this direction for the last 10 to 15 years.
Simon replied that it is very complex, but he still thinks most of the routers that speak BGP are not in tier-2 networks.
Vince replied that it is not the cost of memory that is the concern but the FIB resources. It is the really expensive stuff that, even if it scales price-wise, does not scale for heat and power consumption. Overall cost, in more than just dollars, will still increase.
Geoff Huston commented that it is a multidimensional problem. More routes lead to more updates and as you tend to run out of power, you'll start queueing updates, slowing BGP convergence. At some point, in an unconstrained system, you can't run like this anymore and that routing is an unbounded problem that sooner or later will bite us all.
Gert Döring mentioned that all these enterprises need electricity today and need telephone today, but only a very very small part of the organisations with more than ten employees is using redundant power or telephone providers. If everyone is feeling that internet is so important and reliability is so bad, maybe we should work on reliability.
Vince replied that his 6 million enterprises were mostly a sanity check to see whether his numbers make sense. He does think that it becomes less expensive to become multihomed, it's going to become more attractive. He noted that an additional Internet connection could be only 100 EUR/month, an additional power feed would be a lot more expensive.
4) RPSL analysis service - Massimo Rimondini, Tiziana Refice Massimo
Rimondini gave a presentation on extracting peerings from RPSL.
João suggests that if people try it out and have comments, they should mail them to Massimo.
5) Discussion on WG Charter and Focus - Working Group Chairs
This item will not be covered due to lack of time and will be handled on the mailing list and the next RIPE meeting.
6) AOB
There was no other business.