ISPs who wish to connect customers who have allocations from the multihoming space must
a) announce the whole space aggregated b) peer with other providers who host other customers
As mentioned, this huge aggregate attracts unwanted traffic. It would make more sense if this so-called multi-homing aggregate was to be carved up into smaller aggregates based on the geographical topology of the network. That way, providers whose PoPs are geographically close to each other (in the same city) could use multihoming addresses from the same aggregate. Providers could then choose to only offer multihoming services in those cities where they peer with other multihoming providers. The number of aggregate routes announced mushrooms to about 5,000 because there are that many cities in the world with a population greater than 100,000 people. This geotopological address aggregation will still result in some unwanted traffic but a provider is at liberty to carry more detail internally and hand it off closer to the source. For instance, a provider with PoPs in New York and Paris, could elect to carry all Paris routes in New York in order to shed peer traffic before it crosses the Atlantic. I wonder if the solution to these issues would be facilitated by carrying some additional policy info in a routing protocol. Attributes like ROUTE_COMES_FROM_A_PEER_WHO_SELLS_MULTIHOMING or similar. If there are only 5000 or so peering locations in the world, then perhaps an attribute like ROUTE_HEARD_FROM_PEER_IN_CITY_439 would also be useful. --Michael Dillon