Short version: APT and Ivip greatly reduce the number of
destinations to which a full stream of mapping
updates need to be pushed, compared to
LISP-NERD. So the choice is not just between
full pull (APT, TRRP) and full push (NERD).
Is LISP-ALT a quickie "solution" - with a
better, incompatible, real long-term solution
in the future?
Hi Noel,
I responded to what you wrote about mobility in a separate
thread. You wrote:
> On a more general note, I actually did some 'back of the envelope'
> calculations a year or two ago, trying to decide whether to use push or pull,
> and my recollection is that the update rate numbers (i.e. the control traffic
> at each and every ITR) for push got fairly significant (in terms of the
> number of updates per second) even with only moderate numbers of mapping
> entries, and a fairly low assumed per-entry update rate (e.g. for provider
> changes only).
Sure, that is presumably for LISP-NERD - the only current
proposal which involves every ITR getting the full feed of
mapping updates. I think most people agree LISP-NERD does not
scale well enough to be considered as a lasting solution.
For APT and Ivip, the mapping is pushed to local full-database
query servers. These are much less numerous (factor of 10 to
100 or whatever) than ITRs, which will be caching ITRs.
Also, with Ivip, the caching ITR function can be performed in a
sending host (not behind NAT unless the ITR function opens a
persistent tunnel to its local query server). Ivip has an
optional intermediate layer (or multiple layers) of caching
query servers between the caching ITRs and the local full
database query servers. This may further reduce the number of
full database query servers needed, without adding any
significant delay to the ITR getting the mapping it needs.
Compared to LISP-NERD, this greatly reduces the number of
devices which get the full feed of mapping updates.
> Certainly, a full-push system is going to be distributing lots of mappings to
> boxes that never use them - my guess was something in the 99% region, if not
> much higher. (Long digression on the optimal mapping distribution system
> omitted - the points you raise are certainly valid, but there are good points
> on both sides, and I don't think the answer is clear-cut - if it were,
> we probably wouldn't still be discussing it.)
Sure, but mapping data with Ivip is quite compact, since it only
involves a single ETR address for each micronet. (12 bytes at
most per micronet, but this could be conveyed in a more compact
form, probably down to 8 bytes.) LISP and APT involves multiple
ETR addresses for each EID prefix. Ivip's fast-push mapping
system is intended to be streamlined and will carry multiple
mapping updates (a hundred - or 700 or 800 or so with
jumboframes) per packet.
The volume of mapping changes are just not that big compared to
what ordinary domestic end-users are doing with the Net today.
In a few years time, it will be commonplace for these users to
be getting multiple gigabytes of near-real-time video data,
often from across the world, for a few dollars.
It will be a long time (massive use of TTR mobility) before
LISP, APT, Ivip etc. have mapping update rates to rival the 4 to
8 Mbps video streams which will be sent to ordinary homes.
Updates will be for some mix of:
Changes for multihoming service restoration.
Inbound TE.
A mobile node's micronet being mapped to a new TTR.
Let's say it was all IPv6, with about 32 bytes per mapping change:
64 bits Micronet base address, in units of /64.
64 bits (32 would usually do) Micronet length in the same
units.
128 bits ETR address.
Allowing for a 50% overhead, 1Mbps provides 2600 mapping updates
a second. For arguments' sake, let's say half are mobile TTR
selections, this is 1,300 people a second, on average travelling
something like 1000km. That, on average, is 4.6M an hour - far
more than will ever be needed on this planet using conventional
physics.
Do you have any BOTECs (Back of the Envelope Calculations . . .)
for far distant future mapping update rates? Multiply them by
32 bytes for IPv6 Ivip and consider how bad, on average, that
will be in the context of ISPs in that far distant future.
Peak rates would be higher of course.
> Also, I'm not sure that for those working on LISP, ALT is the 'preferred'
> long-range answer to the question of 'what does the mapping subsystem look
> like'. I think the focus is on ALT at the moment in large part because it's
> fairly easy to deploy, because it re-uses existing code. (Dino et al, please
> correct me to the degree I am confused here.)
I don't recall any other LISP people suggesting this - that ALT
as a first-cut system, to be replaced by something different and
better in the long term.
I think a LISP-ALT router can be created by correctly
configuring existing functions in any suitably flexible hardware
or software-based router. The ITR and ETR functions require
some additional code to be written.
So it is not too hard to get LISP-ALT going. For instance:
http://www.lisp4.net/docs/lisp-ausnog02.ppt Aug 2008 slide 11:
a very small amount of new code was written to support this
It wouldn't be surprising if a better architecture required more
thought and more code and complexity in some areas, such as a
fast-push mapping system and the full-database and caching query
servers. Such an architecture would have greater benefits,
better scaling properties and less complexity and costs where it
really matters, such as in the ITR function.
For instance (not counting the PTMUD functions which are
reasonably complex for Ivip, LISP or any other system) Ivip ITRs
are a lot simpler than LISP ITRs or APT ITRs/DMs because they
don't need to test reachability to ETRs, or make any choices
between different ETRs. Also, the mapping information they
cache is more compact than with LISP or APT.
> It might well make sense to transition to something else in the long run -
If this is true of LISP-ALT, then why bother with it?
What can be learnt by pushing ahead with it, compared to working
on a better architecture instead? The problems with delays,
long-paths, robustness vs. a relatively flat, aggregated ALT
structure etc. have already been pointed out.
> but then of course one has the transition issue to deal with, and from what
> thinking I have put into that particular problem, it's more problematic that
> some of the other long-term transition issues (e.g. to a different inter-xTR
> packet format, etc). So that would argue to make replacement of that
> subsystem priority number one...
With a 15% per annum growth in the DFZ routing table, even if it
accelerates considerably due to finer slicing and dicing of IPv4
space, the sky is not going to fall in this year, the next or by
2015.
If getting the right design takes another few years compared to
adopting a quickie solution, then it will be well worth doing
this extra work.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
