[ppml] geo addressing

[Owen DeLong]

Point is that organizations will have topological needs that don't
will cause geo. addressing to break one way or the other.  Eventually,
this will cause address migration and entropy.

Owen


--On November 22, 2005 4:02:29 PM -0800 Tony Li <tony.li at tony.li> wrote:

>
> On Nov 22, 2005, at 3:46 PM, Owen DeLong wrote:
>
>> What about sites that expand outside the aggregate, want to remain
>> within their own aggregate for administrative purposes, but, also
>> want local connectivity in their various offices around the world?
>>
>> Imagine, for example, that a company in the US, within an ARIN
>> aggregate starts expanding internationally into Asia, Europe,
>> Africa, and Latin America.  Imagine that such company feels that
>> their existing /32 is adequate, but, they want to be able to
>> announce it (or a fraction of it) from their sites on each
>> continent directly.
>>
>> The reality is that geo. addressing only works if the world
>> stands still.  The world does not stand still, so, geo.
>> addressing trends towards entropy.
>
>
> Owen,
>
> What matters is where the individual site is connected.
>
> If a multinational has a HQ in one area, then they should get a
> prefix in that area.  If they have an office in another area, then
> how they should proceed depends entirely on the topological
> situation.
>
> If the remote site is only connected via HQ, then the site should be
> numbered via the HQ prefix.  If the site is only connected locally,
> then they should be numbered out of the local area.  If they are
> connected via both, then we're gonna have the multihoming
> argument (again).
>
> Yes, a strict geographic address proponent would number them
> out of the geographic prefix regardless of connectivity.  That's
> perhaps not the only way...
>
> Tony



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051122/bce90cff/attachment.sig>