Subject: RE: Geo pros and cons

From: "Tony Li" <[email-masked]>
Date: Wed, 2 Apr 2003 11:48:12 -0800

|    From: Tony Hain [mailto:[email-masked]] 
|    > 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.
|    > 
|    Only if you insist on the absolute minimum size routing 
|    table. 

If we were to insist on the minimum size routing table, we would
have to decree that the entire Internet was a single binary tree.
No thanks.

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

If we could provide a mechanism that allows for globally rational
decisions about system cost to be made, we could and would deploy
it today.  You may recall from the CIDR wars that we briefly 
discussed and tried to encourage a mechanism that caused economic
pushback for individual routes in the DFZ.  It never went anywhere.
If you want to charge to accept routes and your competition doesn't,
you lose.

This boils down to simple game theory: we can expect that almost
everyone will act in their own best interest, at the expense of
the common good.  We are not empowered to edict the economics of
the situation, so we'd best come up with a solution that organizes
the chaos that others will foist upon us.

Tony

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 2 Apr 2003 21:34:44 -0500

Just as note one ISP that is large just told us NO WAY.  They stuck to
their guns.  I agreed with them.

/jim

>-----Original Message-----
>From: Tony Li [mailto:[email-masked]] 
>Sent: Wednesday, April 02, 2003 2:50 PM
>To: [email-masked]; marcelo bagnulo
>Cc: Iljitsch van Beijnum; [email-masked]
>Subject: RE: Geo pros and cons
>
>
>
>
>|    You miss the point that the ISPs with the customers 
>|    demanding PI space
>|    would be the ones that would need to connect to the designated geo
>|    interconnects. This aligns the economics with those 
>|    creating the need.
>
>
>You miss the point that those same customers will simply 
>browbeat the ISPs to advertise longer prefixes.
>
>Tony
>
>

---

From: "Grovesteen, Harold" <[email-masked]>
Date: Thu, 3 Apr 2003 07:30:18 -0600

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:[email-masked]]
Sent: Thursday, April 03, 2003 4:33 AM
To: Tony Li
Cc: [email-masked]
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.