design of a real routing v. endpoint id seperation

Michael.Dillon at btradianz.com Michael.Dillon at btradianz.com
Fri Oct 21 09:35:40 UTC 2005


> 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




More information about the NANOG mailing list