On Wed, Jan 28, 2009 at 6:18 PM, Christian Vogt
<[email protected]> wrote:
>
> On Jan 24, 2009, Dino Farinacci wrote:
>
>>> 4 - LISP-ALT's Aggregation implies provider dependence.
>>>    This is Christian Vogt's critique:
>>>    http://psg.com/lists/rrg/2008/msg00259.html
>>
>> Not true. Aggregation here is for the EID-prefix. Service providers do
>> not carry EID-prefixes in their cores so you don't depend on them. The
>> decoupling of the address creates this. The dependence is now on the
>> ALT. And if your site resides in a specific region of the world, you get
>> your EID-prefixes from that registry. So readdressing your domain would
>> only occur if you moved it from one region to another (let's leave
>> mobile ASes out of this for now).
>
>
> Dino -
>
> There is a tradeoff between EID portability and path stretch along the
> ALT topology, and I believe the tradeoff made in LISP/ALT has been
> revised a few times.
>
> Portability of EID prefixes requires that the ALT topology follows
> EID-addressing.  This leads to potentially longer-than-optimal paths
> along the ALT topology.  Vice versa, if path stretch is to be limited,
> then portability of EID prefixes must be restricted.
>
> 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?

-Chris
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg

Reply via email to