Subject: RE: Geo pros and cons

From: "Tony Li" <[email-masked]>
Date: Tue, 1 Apr 2003 15:38:09 -0800

Iljitsch,

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

Since this happens all too frequently, we must deal with it.  The
Internet is not a centrally run function.  Instead it grows
organically by the needs of the users.  In other words, the links
only show up where they make economic sense.  And those are the
links that users will use, ignoring the consequences.

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

If the routes are proportional to the number of areas and the areas
are growing, then you again have a rapidly growing routing table.

As we concluded many years ago: for addressing to scale, it has
to match the topology.  If addressing does not match the topology,
then additional information in the form of longer prefixes must be
advertised into the routing subsystem.  Ergo, if one chooses geographic
address, one must force only geographically based links.  Anything
else destroys the aggregatability of the address assignment.  Since
we, as IETF members, cannot decree where folks will connect, geo 
addressing is a nice theorectical goal which is unimplementable.

Regards,
Tony

---

From: marcelo bagnulo <[email-masked]>
Date: 02 Apr 2003 17:14:17 +0200

Hi Tony,

[...]
> to match the topology.

Fully agree.
I would say that the question is if topology matches geography or not.

I have heard many claims that the Internet is becoming a dense
interconnection mesh. If this is true, it should be easy to determine
geographical areas that are interconnected, so geo aggregation works
without the need of more specific routes.

I think that this is certainly not the case for all geo locations, but i
would say that it is probably the case for some locations as big cities
where a lot of users reside. Wouldn't geo addressing be suitable for
this situations?

I am not aware of any analysis of how dense is the interconnection in
geo areas, but i would say that this input is important when considering
geo addressing. Does anyone have information about this?

Thanks, marcelo

>   If addressing does not match the topology,
-- 
marcelo bagnulo <[email-masked]>
uc3m

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 2 Apr 2003 11:25:37 -0800

Tony Li wrote:
> Since this happens all too frequently, we must deal with it.  
> The Internet is not a centrally run function.  Instead it 
> grows organically by the needs of the users.  In other words, 
> the links only show up where they make economic sense.  And 
> those are the links that users will use, ignoring the consequences.
> 
>     
> If the routes are proportional to the number of areas and the 
> areas are growing, then you again have a rapidly growing 
> routing table.
> 
> As we concluded many years ago: for addressing to scale, it 
> has to match the topology.  If addressing does not match the 
> topology, then additional information in the form of longer 
> prefixes must be advertised into the routing subsystem.  
> Ergo, if one chooses geographic address, one must force only 
> geographically based links.  Anything else destroys the 
> aggregatability of the address assignment.  Since we, as IETF 
> members, cannot decree where folks will connect, geo 
Only if you insist on the absolute minimum size routing table. As you
said above, economics drive the decisions of network managers. There is
a balance somewhere here between circuit costs for random interconnects,
and the cost of the routing table to support that. All we need to do is
provide a mechanism that allows for rational decisions about system cost
to be made. A mechanism that results in lower costs for those that
choose to multihome in a small geographic region will win out.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 3 Apr 2003 12:33:04 +0200

On woensdag, apr 2, 2003, at 01:38 Europe/Amsterdam, Tony Li wrote:

> |    close to home.

> Since this happens all too frequently, we must deal with it.

Sure. But I say we deal with it as an exceptional situation that may 
require additional resources rather than accept this as regular so 
regular mechanisms must be able to fullly support this.

> The Internet is not a centrally run function.  Instead it grows
> only show up where they make economic sense.

Being routable makes economic sense.

> are growing, then you again have a rapidly growing routing table.

The routes are proportional to the number of users in an area. I assert 
that for areas above a certain minimum geographic size, the number of 
users in an area is fairly constant.

> address, one must force only geographically based links.

Aggregation isn't a binary thing. CIDR can aggregate PA address space 
but not PI address space. Before CIDR, PI was the norm but now it's 
quite rare. With geographical aggregation the same will happen: in the 
beginning, aggregation will be limited. But unlike CIDR, you don't have 
to renumber to start aggregating: when a new local or regional link 
becomes available, you immediately gain aggregation.

Also, the requirement for "geographically based links" doesn't have to 
be all that bad. If network A wants to handle the Italy geo region in 
Milan, but network B wants to do this in Chicago, they can use a 
"geographically based link" to peer between A's Milan router and B's 
Chicago router. With something like ATM or MPLS this is easy to 
implement.

> Anything

I agree that geographic aggregation doesn't look all that good in 
theory, and that it lacks long term scalability. However, it's still 
much, much better than "straight PI" where we know the potential for 
aggregation is 0. For geo, we know the potential for aggregation is 
less than 1, but at least it's more than 0. So in the absense of better 
short-term solutions (unless you include forbidding multihoming as a 
short term "solution") and considering the fact that this can be 
implemented relatively painlessly, I think it is worth it.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 3 Apr 2003 13:51:58 +0300 (EEST)

On Thu, 3 Apr 2003, Iljitsch van Beijnum wrote:
>                                          So in the absense of better 

I would not classify geo as a short-term solution.

Sure, it can be implemented rather quickly, no doubt about that.  For the
first years "geo" is probably just a shorthand for "advertise full /48's
from under specific geo-prefix".  And in 3-5 years when we try to start
aggregating, we might run into troubles.  And what do we do if we can't 
solve those problems sufficiently?

But can it be unimplemented if that's seen fit?  Doesn't seem likely.

So it seems to me that if we go for geo, we go for good.  Which is why a
lot of deliberation is required.

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 3 Apr 2003 14:22:33 +0200

On donderdag, apr 3, 2003, at 12:51 Europe/Amsterdam, Pekka Savola 

> I would not classify geo as a short-term solution.

Short to intermediate term.

> from under specific geo-prefix".

Agree.

> And in 3-5 years when we try to start

We have to make sure we know in advance that we can handle all 
reasonable eventualities.

> But can it be unimplemented if that's seen fit?  Doesn't seem likely.

The idea is that we create an upgrade path. Geographically aggregatable 
PI addresses could be used as identifiers in an identifier/locator 
separation solution. That way, we can get rid of the geo /48s in the 
routing table without the need for renumbering.

 From your previous message:

> 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)?

ISPs are _supposed_ to announce all geo /48s for their customers 
everywhere. Aggregation happens inside each individual ISP network by 
creating private aggregates and selectively filtering geo /48s in 
certain routers. The only way for peer networks to frustrate aggration 
is to not interconnect or not announce geo /48s in the expected 
interconnect location.

It seems likely that the largest networks will gravitate towards a 
common level of aggregation that conforms to the level of 
interconnection between those networks. Successfully aggregating more 
aggressively than this will be hard, and not announcing geo /48s in the 
closest place you interconnect makes no sense.

When this has happened, smaller networks will be forced to play along 
and interconnect there where the large networks expect them to because 
large networks often can't be bothered to peer anyway, and breaking 
aggregation isn't likely to be a plus.

For smaller networks aggregating is simple, as they can always dump 
traffic for which they have aggregated away the /48s in one of their 
transit's laps.