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.
Yes, but if you are portable within an aggregate boundary, you are okay.
Portability of EID prefixes requires that the ALT topology follows
EID-addressing. This leads to potentially longer-than-optimal paths
And it does.
along the ALT topology. Vice versa, if path stretch is to be limited,
then portability of EID prefixes must be restricted.
I envision the number of hops a Map-Request takes is 4 ALT-router
hops. I think we can do that with how the aggregation and allocation
assignment is done on the LISP network now.
Now if the diameter of the tunnels are large, then there will be
longer delays because the Map-Request will have to travel more
physical hops.
But I really think you are not going to find a better way.
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.
Right that is the tradeoff, but a site in Europe is not going to move
to the US. A new site that is added in the US will get EID-prefixes
from ARIN and terminate it's tunnels to the routers in the allocation
assignment hierarchy for ARIN.
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.
Christian, when you come to IETF in the US and you use your VPN client
to connect back home to Finland, and you go to a URL in San Jose (when
you are at the SF IETF), your packets will to east over the Atlantic
twice and back to the west coast. That's a delay we all seem to live
with everyday.
I am not justifying delay and I'm not at all saying this is going to
happen on the ALT either. Remember this only happens for the first few
packets to a new site when there is a cache miss from each ITR.
You cannot push around 10^10 entries and store them everywhere. In
fact there are chances with a push technology that you might have to
store them in nodes that won't need them for use but will need to
store them for distribution. That will be a big cost. So then you go
get them when you need them.
Please recall, for LISP to support such a large database (10^10
entries), it must be distributed. And you want them to be stored where
the policy holders are for the mapping and you wan them to reside at
the site that the mapping describes them.
Dino
- Christian
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
