RE: Geo pros and cons

["Grovesteen, Harold" <Grovesteen@aafes.com>]

This definitely gets my vote!  This solves my short term problem (next two
years) without destroying the longer term goals of PA.  After that I could
easily be faced with bigger issues.  My other short term answer is two 6to4
tunnels to each of my two IPv6 transit providers sourced from two routers.
This provides identical reachability and failure survivability as IPv4 and
eliminates the address selection issues and ingress filtering problems for
either clients or servers (the priority for me).  Both prefixes are
advertised by both IPv6 transit providers.  Not clean but workable.  Just
have to get the transit provider to agree to two tunnels.  That's where the
brow beating comes in.

Harold Grovesteen

-----Original Message-----
From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]
Sent: Thursday, April 03, 2003 4:33 AM
To: Tony Li
Cc: multi6@ops.ietf.org
Subject: Re: Geo pros and cons


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

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

> 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
> organically by the needs of the users.  In other words, the links
> only show up where they make economic sense.

Being routable makes economic sense.

> If the routes are proportional to the number of areas and the areas
> 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.

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

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

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.