[89281] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: shim6 @ NANOG

daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Mar 6 16:08:43 2006

Date: Mon, 06 Mar 2006 13:08:03 -0800
From: Owen DeLong <owen@delong.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>,
	Roland Dobbins <rdobbins@cisco.com>
Cc: nanog@nanog.org
In-Reply-To: <83E1EAB8-4D36-4C5D-92D4-E212C7557ED4@muada.com>
Errors-To: owner-nanog@merit.edu


--==========22EFF60FBBA81CA8FA8D==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline



--On March 6, 2006 12:46:51 PM +0100 Iljitsch van Beijnum
<iljitsch@muada.com> wrote:

> 
> On 6-mrt-2006, at 3:52, Roland Dobbins wrote:
> 
>> fixed geographic allocations (another nonstarter for reasons which  
>> have been elucidated previously)
> 
> What I hear is "any type of geography can't work because network
> topology != geography". That's like saying cars can't work because  they
> can't drive over water which covers 70% of the earth's surface.
> 
No, it's more like saying "Cars which can't operate off of freeways
won't work" because there are a lot of places freeways don't go.
Hmmm... Come to think of it, I haven't seen anyone selling a car
which won't operate off of a freeway.

> Early proposals for doing any geographic stuff were fatally flawed  but
> there is enough correlation between geography and topology to  allow for
> useful savings. Even if it's only at the continent level  that would
> allow for about an 80% reduction of routing tables in the  future when
> other continents reach the same level of multihoming as  North America
> and Europe.


I've got no opposition to issuing addresses based on some geotop. design,
simply because on the off chance it does provide useful aggregation, why
not.  OTOH, I haven't seen anyone propose geotop allocation as a policy
in the ARIN region (hint to those pushing for it).

Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.

--==========22EFF60FBBA81CA8FA8D==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFEDKS0n5zKWQ/iqj0RAu5+AJsGACchnC8M5GAPwS9IrEm+CrF5XQCfdrYE
bKm3PThP/VlcXnctfiH1wUM=
=PcY1
-----END PGP SIGNATURE-----

--==========22EFF60FBBA81CA8FA8D==========--


home help back first fref pref prev next nref lref last post