On 2009-02-03 09:31, David Meyer wrote:
> On Mon, Feb 02, 2009 at 01:42:47PM -0500, Scott Brim wrote:
>> Excerpts from Christopher Morrow on Mon, Feb 02, 2009 01:21:19PM -0500:
>>>> According to your email to Robin, LISP/ALT currently makes the following
>>>> tradeoff: Portability of EID prefixes is limited geographically in
>>>> order to curb path stretch along the ALT topology to the maximum that
>>>> can happen within a geographical region.
>>>>
>>>> That's possible, of course. The cost is that networks scattered over
>>>> different parts of the world, such as those of enterprises with global
>>>> presence, cannot use a continuous address space internally -- even if
>>>> they all attach to the same provider.
>>> cant they? I thought one of the nice things about the loc/id split was
>>> I could number my internals out of whatever I wanted, spread over
>>> creation and the attachment points were the only things that required
>>> aggregation, no?
>> Sure, but if one of your sites is in New Zealand, and has a prefix
>> where the physical ALT hierarchy is optimized for sites in Europe, a
>> source in New Zealand trying to contact your site would see more delay
>> during the Map-Request/Reply exchange, even though it they are in the
>> same town. However, Map-Request/Reply exchanges don't happen very
>> often, and the delay will be low (round trip across the Internet).
>
> Or not at all if you're not the first folks communicating
> between the sites.
A couple of points on this.
1. Large companies with their own international networks will
surely never adopt a solution which doesn't allow them to have
a straightforward, consistent and 100% internally managed
addressing plan.
2. They also won't adopt a solution in which local customers
experience world-crossing delays for accessing local sites.
They will use DNS tricks, redirects, CDNs, and overlay routing
to get round this.
It's to be hoped that loc/id solutions such as LISP will be viewed
as a help in this game rather than as a new enemy.
Brian
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
