In http://psg.com/lists/rrg/2008/msg01345.html, Tony Li wrote that there was no catastrophic limit to the growth in the DFZ routing table.
>> What do the big router implementers on this list think about the >> question of when we will hit a "catastrophic" scaling limit ? > > 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. > > If you believe this, then the issue is real and is strategic, not > tactical. We have the opportunity to Do It Right, and we should. I agree. The Internet's routing scaling problem is not like a damsel bound to the railway tracks with the 6 O'Clock Express bearing down upon her. The scaling problem results in growing costs and difficulties which flow to all Internet users as it becomes more and more expensive to field DFZ routers, and as end-user networks find it harder and harder to get the portable, multihomable IPv4 address space they need. Technically, it would be possible to solve the routing scaling problem (thereby providing portable, multihomable address space for hundreds of millions of end-user networks) by a major architectural change which involves a new system of identifiers, and therefore involves changes to applications and operating systems, as Bill Herrin wrote: http://psg.com/lists/rrg/2008/msg01349.html RW > Can we form rough consensus on this? RW > RW > Short version: RW > RW > End-user networks need their own portable address space. > > Concur but I want to explicitly state the assumption: > > [In any complex internet in which the host network address is > not strictly ephemeral,] end-user networks need their own > portable address space. > > In theory, we could redesign IP from the ground up so that the > hostname was king and the network addresses assigned to a > particular machine could change at any time without disrupting > communications. In practice, we're not going to and if we were > going to it would be far beyond the scope of this working > group. This leaves us at your conclusion. In offlist discussions I also learnt that at least one RRG member is keen for a solution which would help with intra-network failures, so a host with two interfaces and so two IP addresses, could keep working on the one session, even when one interface fails or is unreachable. SCTP (and maybe SHIM6 and Six/One?) already does this, as far as I know. However I think he envisages an RRG solution which underlies all existing communications, which would involve impractical lower levels of stack modifications (maybe global routing stuff too?) to protect TCP, UDP, ICMP etc. sessions as well - or perhaps such a solution would also new applications, new OS functions etc. The map-encap solutions (and Six/One router too?) are all based on the assumption that we can't mess with applications or host stacks - because we need to have a solution implementable at the network level. A network-level solution is the only way of providing the required centralised (ie. robust, simple, secure) control over portability, multihoming and TE and also the only practical way of applying a new architectural enhancement. Any proposal which requires changes to host OSes would be difficult or impossible to implement with the required 100% success in a sufficiently high proportion o end-user networks - and application changes are out of the question. I think the map-encap schemes are also based on the assumption that the routing scaling problem should be solved purely at an IP address level - for both IPv4 and IPv6. These map-encap solutions (LISP-NERD, LISP-ALT, APT, Ivip and TRRP) are the only potentially practical complete systems which have been proposed since RAWS. They are all based on the notion that the solution needs to work with all existing applications and host stacks. I think that for the RRG to make any meaningful contribution, we need to define the scope of Tony's "It" clearly, such as this: The RRG's proposed solution to the routing scaling problem will work for both IPv4 and IPv6, and be capable of widespread adoption based primarily or solely on the immediate benefits it provides to end-user networks and ISPs. To this end, the solution will not attempt to alter host-level Internet protocols in any way, but will operate purely at the level of IP addresses, and with mechanisms by which packets are transited across the generally unmodified DFZ, from and to the new network elements and/or new router functions defined by the solution. There has long been, and remains, a desirable goal of having applications work with end-point identifiers which remain stable despite the workings of the routing system - in particular regarding outages, network reconfiguration, portability, multihoming and traffic engineering. Any solution to the routing scaling problem which relies on such changes is beyond the scope of the RRG, because it involves host changes and deployment hurdles which cannot be solved within the (five?) years we have to tackle the routing scaling problem. Such approaches would best be developed in a separate forum, with a longer time-frame and a much more ambitious scope. - 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
