Hi Nick, On Thu, 1 Feb 1996 02:32:11 +0100 "Nick Vermeulen" wrote:

imho, most multi-homed sites can do with a partial routing table; organisations who want or need to have full routing tables should put extra RAM in their backbonerouters to meet demand. When 64 MByte isn't enough anymore...buy a cisco 7500 series which can hold 128 MByte RAM. you can minimize the number of your full-routingtable routers with ebgp multihop features (for multi-homed customers) in the mean time...monitoring routing tables and notifying net-admins that advertise less efficient aggregates will help.

If the problem is just adding a few SIMMs then people would do that. The real problem is that current routing protocols require more growth in resources such as CPU and memory than technology improvements can offer. One can roughly say that CPU's double in speed every 24 months; and as you know the Internet doubles every 10 months, thus the net grows faster than new technology can offer additional resources. The only way to cope with that is to make a 100% growth of the net result in much less than a 100% growth in resource requirements; the only mechanism of which we know it's working is hierarchical routing, which requires people to renumber if they change provider. If people don't renumber, then they will add significantly to the strain the net is seeing already and the whole discussion started because one of the US ISP's announced to implement some policy to archieve this which has very bad side effects. There are a couple of approaches to archive hierarchical routing: - prefix-length filtering as announced by said US ISP (this is by far the worst choice IMHO) - prefix-charging (this has some non-technical problems which aren't resolved yet) - community consensus on limitation of prefixes The whole issue has been discussed at the RIPE-meeting earlier this week; I don't think I saw you there. It isn't a matter of adding some SIMMs; some of the people who have brought up their concern on this are running Cisco hardware that isn't even available commercially yet, and yet need to do everything they can to keep their boxes running. They are seeing some 50% of CPU utilisation on their routers during normal operation, see the growth curve in this and know that once it reaches 100% (causing the box to roll over and die), they won't be able to buy a faster box because none is available. I have seen MCI slow-starting one of its routers by hand during the IETF in Dallas some weeks ago and it was a very scary sight. The technical background on the current problems has been discussed back and forth on the IETF CIDRD working group, and I invite you to read the mailing list archives as your suggestion and its problems has been discussed there already. I'm attaching the charter of the WG below for your convienence. Geert Jan --- CIDR Deployment (cidrd) ----------------------- Charter Current status: active working group Chair(s): Vince Fuller <vaf@bbnplanet.com> Tony Li <tli@cisco.com> Operational Requirements Area Director(s): Scott Bradner <sob@harvard.edu> Michael O'Dell <mo@uunet.uu.net> Mailing lists: General Discussion:cidrd@iepg.org To Subscribe: cidrd-request@iepg.org Archive: ftp://aarnet.edu.au/pub/mailing-lists/cidrd* Description of Working Group: The CIDR Deployment Working Group will be a forum for coordinating the deployment, engineering, and operation of classless routing protocols and procedures in the global Internet. This activity will include, but not be limited to: - Deployment of CIDR addressing and routing in the global Internet. Will include coordination of deployment of new exterior routing protocols, such as BGP4, which support CIDR. - Develop mechanisms and procedures for sharing operational information to aim the operation. - Development of procedures, policies, and mechanisms to improve the utilization efficiency of the IPv4 address space. - Work on longer-term strategies for hierarchical, CIDR-based addressing and routing. Examples include class A subnetting and provider block sub-allocation along geographical/topological boundaries as is done for 193.0.0.0 and 194.0.0.0 in Europe. Initially, this working group will be simply the reincarnation of the BGP Deployment Working Group under a new name. Goals and Milestones: Ongoing Provide forum for discussion of initial CIDR/BGP4 deployment on the global Internet. Done Establish final charter, goals, and long-term group agenda. Feb 94 Work on inter-provider coordination of routing in the CIDR environment. Apr 94 Publish initial guideline document on CIDR allocation procedures (work in progress). Apr 94 Publish guidelines for usage of variable-length subnetting. Apr 94 Start work on document of inter-provider routing coordination. Apr 94 Begin work on document of aggregation guidelines. Jul 94 Begin work on document for long-term CIDR use, including subnetting of class As. Internet-Drafts: Posted Revised I-D Title <Filename> ------ ------- ------------------------------------------ May 95 Jan 96 <draft-ietf-cidrd-addr-ownership-07.txt> Implications of Various Address Allocation Policies for Internet Routing May 95 Oct 95 <draft-ietf-cidrd-appeal-03.txt> An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA May 95 New <draft-ietf-cidrd-classless-inaddr-00.txt> Classless in-addr.arpa delegation May 95 Dec 95 <draft-ietf-cidrd-classa-01.txt> Observations on the use of Components of the Class A Address Space within the Internet Jul 95 Jan 96 <draft-ietf-cidrd-private-addr-05.txt> Address Allocation for Private Internets Request For Comments: None to date.