Can we agree that we need to recommend a fix for the IPv4 routing scaling problem - and that this is our most urgent priority? I propose some text for potential consensus in a separate message "Take 2: AA, BB, CC".
Here are some arguments about why we need to fix IPv4 first. In the thread: "Re: [RRG] Long term clean-slate only for the RRG?" Yakov Rekhter wrote: > Perhaps we should first agree that there is a need a *short term* > solution for both IPv4 and IPv6. The following (from Tony's e-mail > on 5/26/2008) is relevant to the discussion on whether there is > such a need: > > Well, Ross Callon has been quoted as saying that the Juniper > implementation will have no problems up through many millions > of routes. > > Now, conceptually, that could happen tomorrow. However, at the > current growth rates, that's likely to be many years. Previously, in http://psg.com/lists/rrg/2008/msg01612.html, Brian Carpenter wrote: > Dino Farinacci wrote: > ... >> Could we agree that one map-n-encap solution for both IPv4 and >> IPv6 be a short-term solution while we work on a long-term >> solution for IPv6-only? > > Clarifying question: do we have to hold our breath while > waiting for the long term solution? > > But seriously - since it doesn't seem that we want to shrug our > shoulders over IPv4, and I don't see the industry being willing > to support two solutions, I don't see much choice. I agree we can't shrug our shoulders and let today's Internet degenerate, solely on the basis that we are devising another Internet to which we assume everyone will happily migrate before too long. I would much rather develop a long-term solution at a relaxed pace without expecting the rest of the world to hold its breath and wait for our great creation to be ready for mass inhabitation. Some other perspectives which seem to be critical of the view that router technology will cope acceptably with the IPv4 routing scaling problem - so we don't need to fix it and should concentrate on an IPv6 or clean-slate solution: In a message which was addressed to the list, but has not so far been propagated, Eliot Lear wrote: > Yakov, > > If IPv6 is any measure it could take 15 years to deploy the next > thing. Are you are willing to categorically state that there is > no problem for that period of time? Dino wrote: > The routing table size problem is not the only problem. There are > many enterprise sites that want to do low-cost multihoming, they > want to be good citizens to the Internet and don't want to inject > more specifics, and they want to control their ingress traffic > flows. Regarding the quote from Russ Callon: it is no surprise people from the big router vendors say they can build routers to handle "many millions of routes". I am sure they can, for a price. They would be averse to stating there was some limit to their technical capability. However, Tony Li and maybe others in the RAWS workshop did point out that relying on Moore's Law to cope with the scaling problem was unrealistic. http://www.iab.org/about/workshops/routingandaddressing/Router_Scalability.pdf One difficulty with throwing silicon at the problem is that at some point, the job has to be split between multiple CPUs with their own RAM. This raises some really nasty problems with costs, software complexity and the CPU resources devoted to those separate route processor systems communicating with each other so they behave as one. Likewise, fail-over protection becomes trickier still. There are several other problems with this "millions of routes" idea. Firstly, there are stability concerns with the BGP system handling such numbers of advertised prefixes. Secondly the number of routes a DFZ router can handle depends very much on its memory and CPU capacity, in terms of how it handles the number of DFZ routes *multiplied* by the number of interfaces which link to other DFZ routers. In broad principle, the router has to maintain a separate "conversation" about each route with each DFZ neighbour router - and so has to engage in communications, store state etc. in proportion to the total number of such "conversations". So the adequacy of a "millions of routes" router in a particular location depends just as critically on how many DFZ neighbours it has as on how many routes there are in the DFZ. (It has been hard to determine how many DFZ routers there are, but a figure of 210k is regarded as a minimum. Also, there is limited information about the distribution of the numbers of neighbours. See the "Routers in DFZ - reliable figures from iPlane" thread: http://psg.com/lists/rrg/2007/msg00253.html http://psg.com/lists/rrg/2007/msg00255.html http://psg.com/lists/rrg/2007/msg00257.html http://psg.com/lists/rrg/2007/msg00262.html ) Thirdly, these mega routers are going to cost significantly more than routers with CPU and RAM resources suitable for current (~260k) numbers of DFZ routes. Depending on the number of DFZ neighbours for any given router, and the growth in the number of DFZ routes in the years to come, all DFZ routers may need to be replaced with these expensive things. To the extent that these more expensive replacements occur partially or solely due to the growth in the number of DFZ routes, then this is a direct cost burden on ISPs and transit providers which could be avoided by a solution for IPv4. These costs are ultimately paid by all Internet users. (The trick is to devise a scalability solution where the costs of adoption are less than the immediate benefits, so it will be widely adopted.) Since such costs of mega routers depend in part on the number of DFZ routes, unconstrained growth in this number will cause increasingly strong pressure against the further splitting up of the IPv4 address space via the current BGP-only address management system. This further increases the costs and difficulties faced by the growing number of end-user networks which need, but can't get, portable, multihomable space. The above seems to be restating the themes of RAWS 1.66 years ago: http://tools.ietf.org/html/rfc4984 http://www.iab.org/about/workshops/routingandaddressing/ which itself largely involved restating concerns which have been known for 16 or so years earlier. All along this process, as far as I can see, some folks have been focusing on fixing the IPv4 routing scaling problem first, while others have been thinking it would be OK not to worry about it, and to get IPv6 ship-shape in time for the mass adoption which has always been expected "in the next few years". Now, some people foresee IPv4 becoming rapidly more unworkable due to the address depletion problem, which buoys their hopes for the long-awaited mass-migration to IPv6. I have argued there is a lot of scope, especially with map-encap, for extending the productive life of IPv4: Many more end-user networks could get their own portable, multihomable prefixes via map-encap, with little burden on the number of DFZ prefixes. This is true as long as the DFZ prefixes which are the "Mapped Address Blocks" (Ivip terminology) the map-encap system splits into micronets (Ivip) or EID prefixes (LISP) are generally big blocks split which are split into many smaller blocks for large numbers end-user networks. Opinions vary widely on how realistic this scenario is. It depends a lot on our visions of end-user networks, how small a patch of portable, multihomable, public space they would be happy with, how we think IPv4 space could be managed with map-encap, how address space would in fact be managed as the address crunch develops etc. Most people don't foresee much scope for improving IPv4 utilization, but I think there will be enormous pressure to do this, and various methods, including map-encap, will be devised to achieve it. We have 0.75 years before the RRG's deadline. We are supposedly going to produce a "single recommendation", but I don't see how this is realistic. It would take years to decide reliably on a long-term solution - probably involving a radically new architecture, protocols and therefore stack and applications. I think we may be able to devise an optimal solution for IPv4. Maybe we could do the same for IPv6 too. However, that is not so urgent. Yet we want to have some idea about potential IPv6 or clean slate solutions to help us make the IPv4 solution as compatible as possible with the long-term solution. I think there is something more important than theoretical discussions on commonalities between architectures, such as Lixia's focus: http://psg.com/lists/rrg/2008/msg01599.html >> The most substantial solutions to the routing scaling problem >> proposed so far are: >> >> LISP-NERD >> LISP-ALT >> APT >> Ivip >> TRRP >> Six/One Router > > From architectural view, I'd identify the commonality of > all the above as stopping topology-aggregatable prefixes at > the boundary of edge sites, not which version of IP they > may/not work with. While this is true, Six/One Router can't solve the IPv4 scaling problem. Since I think we need to work fast on IPv4 and can take more time with IPv6 and clean-slate solutions, the question of whether an architectural enhancement can support IPv4 is of primary importance in our most urgent work. In other words, we can't afford to ignore important "details" such as the differences between IPv4 and IPv6, and which potential solutions are applicable to them. IPv4 is the only current problem. Unless we are very relaxed about continuing shortage of multihomable space for end-user networks, the pressure this puts on the scaling problem when using BGP-managed PI space for this purpose, the costs this places on ISPs, and the difficulties faced by the end-user networks who can't get the space they need, then this is a problem which needs to be fixed in the next 5 to 8 years. We can't reliably expect to have an alternative, scalable, Internet widely adopted anywhere near soon enough to bring the IPv4 problem to a halt in an acceptably short time. Supporters of the contrary line - that we don't need to fix IPv4, or that we can maybe fix it after we have figured out an IPv6 or clean-slate solution - need to argue convincingly about development and deployment times for their non-IPv4 solutions. Then they need to argue convincingly why most end-users would adopt new applications, new IPv6 (or whatever) Internet services, and reconfigure their entire networks and IT systems (to dual stack initially), in a sufficient short time that the IPv4 scaling problem would be acceptably limited. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
