Subject: Geo pros and cons

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 2 Apr 2003 00:39:04 +0200

In the discussion about geographical aggregation the past days (and on 
earlier occasions) we tend to get into a lot of detail: which routes go 
where, how many interconnects and so on. These are important details, 
and they need to be discussed. But first we need to consider the 
viability of geographical aggregation.

Geographical aggregation has some problems. For instance, it won't 
scale in the long term if we indeed reach multihoming levels of 1 : 10. 
Another problem is that it changes the way traffic flows between ISPs 
(no more hot potato routing).

But the biggest objection against it is that network topologies don't 
match geography, so geography isn't a reasonable basis for making 
routing decisions. I think this is the one we need to tackle.

Now obviously it is possible to lease a circuit to a remote location 
and connect to "the internet" in that location rather than close to 
home. But should we consider this a feature we must support, or is it 
an exceptional situation that we can safely ignore?

Suppose the long distance connection would have been IP rather than 
ATM, SONET or fiber. In that case, a data from customer A of the long 
distance service provider to customer B of the long distance provider, 
wouldn't travel all the way to the remote location and back, but the 
data would be immediately forwarded to the right destination by a local 
router. So essentially we're expecting IP to compensate for the 
stupidity of non-IP networks...

Then there is the argument that interconnection is limited. Yes, this 
is true. Only a small percentage of all internet users live very close 
to a major exchange location (a single exchange location usually has 
one or more public exchanges and several private interconnects). On the 
other hand, the percentage of internet users that live extremely far 
from an exchange location is also fairly low. Experience has shown that 
there is little incentive to implement additional interconnects if 
there is already good interconnection within 500 - 1000 km. If there 
isn't a good interconnect within 1000 km, the need for one is roughly 
proportional to the number of internet users multiplied by the distance 
to the nearest exchange location.

Since the scalability of geographical aggregation depends on the number 
of internet users and the size of the aggregation areas, where each 
aggregation area needs at least two interconnects, it would seem that 
the scalability of geographical multihoming isn't a problem: more 
multihomers means more routes in an area, but since more end-users 
means more interconnects, the areas shrink. So the number of routes per 
area should remain fairly constant.

I'm interested to hear other views.

Iljitsch van Beijnum

---

From: Pekka Savola <[email-masked]>
Date: Wed, 2 Apr 2003 10:23:31 +0300 (EEST)

One particular point..

> area should remain fairly constant.

.. depending on who is in charge of the aggregate and the routes, I've 
gotten a personal belief that if we build a system that allows more 
specific routes, we must have a system which can be used to block them 
too.

That is, e.g. longer prefixes from under current 2001 RIR allocations are 
a non-starter; they create a system where advertising more specifics is 
required for multihomers while giving away the control of more 
restrictions of more specifics.  "meant for longer prefixes of a certain 
length" allocations from a separate block would be completely different in 
this regard.

Similar seems to apply to geo-like approaches depending on geo-aggregates.  
Who (at the originating region) is creating the aggregate?  And more 
importantly, *why* should the sites or ISP's in the region be encouraged 
to *not* advertise their more specific geo prefix *anyway* (assuming the 
geo routing infrastructure might require that under some conditions)?  
There would seem to be a need for some control there, or all the traffic 
going through such big ISP's we could trust to do the right thing and not 
propagating the more specifics.

Otherwise we would end up with a routing table with *both* more specific
geo routes *and* the aggregates :-(

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings