Policy Statement on Address Space Allocations

> 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.

This is all supposing you can only use ONE router for that specific CPU 
intensive task you have in mind. Now please correct me if I'm wrong, but 
if a router with full routing from 10 peers can't handle things, why not 
deploy another router and let both of them handle half the peers.

> There are a couple of approaches to archive hierarchical routing:

Let's turn the problem around and have a look at it from a different 
perspective. The problem is: too many routes. Solutions: renumber and 
aggregate. Renumbering should be happening as we speak... About 
aggregation: this isn't always possible. Many people want to be 
dual-homed to avoid loss of service. A few days ago, I proposed that in 
stead of using provider independent address space, multihomed customers 
should use provider aggregatable address space so that if their long 
prefix suffers filtering, they only suffer partial unreachability.

Now here version two of my proposal:

Address space that is aggregatable by TWO (maybe even more) service 
providers.

That way at least ISP's are able to aggregate the customers they have in 
common. Suppose ISPs A, B and C all have 100 customers. 10% of those are 
multihomed. That would make for one or a few announcements for the 90 
customers that aren't (maybe 10 announcements for A, B and C together). 
And another 15 announcements from the 15 multihomed customers. But if we 
create A-B, B-C and C-A aggregates, there would only be another 3 routes. 
This amounts to considerable savings, even if any two given ISPs only 
have a small amount of multi-homed customers in common.