Short version: Since WG participants presumably believe that
LISP-ALT is either the only possible solution to
the scalable routing problem, or that it is
clearly superior to the alternatives (LISP-NERD,
APT and Ivip), then AFAIK the WG must be planning
to make LISP-ALT work in a future scenario in
which the great majority of its hundreds of
millions of EIDs are for individual mobile devices.
If the scalable routing solution doesn't need to
handle mobile devices, then there will never be
more than a few million, perhaps 10 million, EIDs.
LISP-NERD, APT or Ivip could scale to 10M EIDs
without any fuss. Any of these would all be
superior to LISP-ALT since none of them involve
delaying initial packets or depending on a
global-scale query server system - as ALT does.
NERD is nice and simple - nice and fast. If we
are not trying to do mass-market mobility, NERD
would be a better solution than ALT.
To complete this initial phase of work the WG
needs to establish a coherent plan for how LISP
would be deployed - how it would work in the next
few years and in the decades to come. That means
you need to plan how LISP will handle hundreds of
millions or billions of mobile devices, each with
its own EID.
While I understand that development of LISP-mobile is out of scope
for the WG as currently chartered, I want to make two points.
Firstly, anyone who is interested in LISP-mobile will probably find
it interesting to read my critique a month ago:
Critique of Mobile LISP: draft-meyer-lisp-mn-00 - why not use the
TTR approach instead?
http://www.ietf.org/mail-archive/web/lisp/current/msg00772.html
No-one has responded to this on list or privately. If Mobility is
out of scope for the WG, the RRG would be a good place to discuss it.
Secondly, as part of developing a well documented and hopefully
widely shared set of principles about what LISP is, how it is to be
deployed etc.:
Discussing LISP deployment
Sam Hartman 2009-08-22
http://www.ietf.org/mail-archive/web/lisp/current/msg01092.html
I believe the WG must plan how LISP will do mobility. (I believe it
can, but only with the TTR mobility approach and not at all with the
approach of the recent LISP-mobile I-D.)
The entire WG effort to develop LISP is based on using the ALT
mapping distribution system, which is a successor to CONS.
Both ALT and CONS go to a lot of trouble to avoid any one device
having to store the entire mapping database. The primary or perhaps
only reason for doing this is so that LISP can scale to very large
numbers of EIDs.
AFAIK, the *only* reason you are pursuing ALT, instead of the
alternatives, is because of this goal of seemingly endless EID
scalability.
I think everyone currently working on LISP ALT, or any similarly
endlessly scalable successor to ALT, needs to justify all this
effort, and all the difficulties this goal entails for scalable
routing and therefore all future Internet users, in terms of there
actually being a need, albeit in the long-term, for such large
numbers of EIDs that no other simpler alternative would be able to cope.
The most obvious alternative is LISP-NERD: every ITR downloads the
entire mapping database via HTTP or whatever from a bunch of servers.
Then it is pretty easy for end-user networks to update the mapping
in the central servers and let the changes propagate to all ITRs.
NERD is simple and fast. There are no delayed or dropped packets as
there are with ALT. There is no fancy mapping distribution network -
no complex ALT network of routers with their long-paths, bottlenecks,
etc.
NERD sits at the "simple" extreme of the spectrum. ALT sits at the
other end.
In between are two systems - APT and Ivip - which involve ITRs
getting mapping in a few milliseconds, via a local query server.
This gives APT and Ivip the same major advantage as NERD compared to
ALT: no significant delays in ITRs tunneling initial packets.
Likewise, these three systems have the advantage over ALT that there
is no real-time, moment-to-moment, dependency on a global query
server system, with all its potential and likely delays and packet
loss problems.
Both APT and Ivip enable most or all ITRs to be caching ITRs - since
they use local (such as in the same ISP) full database query servers.
So APT and Ivip ITRs are simpler and cheaper than NERD ITRs.
Therefore they can be more plentiful, closer to sending hosts - or in
the case of Ivip, *in* sending hosts (not behind NAT).
ALT incurs major costs of complexity, global dependencies for ITRs to
work at all moment-to-moment - and most seriously it will delay
initial packets of a significant number of new communication flows,
by times such as fractions of a second to one or two seconds. That
will make it very hard for us to get it widely adopted.
In order to justify pursing ALT, I understand you all must be
proceeding on the basis that none of the alternatives (LISP-NERD, APT
or Ivip) could possibly do the job.
ALT has a bunch of disadvantages over these three, and AFAIK only one
potential advantage: the mapping database is entirely distributed, so
it can (in principle) handle vast numbers of EIDs without scaling
problems in any one device.
To establish that ALT is the only realistic approach to scalable
routing, AFAIK, you need to prove to yourselves that ALT's endless
scalability is absolutely essential to the successful long-term
resolution of the routing scalability problem.
In order to do this, I think you would need to establish three things
at least:
1 - That there will be a demand for a very high number of EIDs -
say YYY million EIDs.
2 - That ALT can scale well, solving the routing scalability
problem, handling this number YYY million EIDs, at some time
in the future when this number will be needed.
3 - That no other alternative (currently LISP-NERD, APT or Ivip)
could be developed to the point where it could handle YYY
million EIDs, whenever in the future (2020, 2030 etc.) these
will be required.
Lets toss some numbers around.
At what number of EIDs would LISP-NERD encounter serious scaling
problems? Lets think IPv6 mapping with (I guess) about 100 bytes per
EID. PCs today (and therefore today's servers and dedicated routers
in a few years time) have 8, 12 or whatever GB of RAM. They have
terabyte hard drives too. Even for ECC RAM, the cost is
insignificant in the scheme of things.
A LISP-NERD ITR will be a caching ITR with packet switching in
hardware or software - co-located with a full database query server.
The query server would be in the same box, including the same
server/router, or in the same rack just one or two patch cables away.
I will assume the full mapping database sits in RAM.
Even if every EID consumed 256 bytes of RAM, a 12GB machine can
handle 48 million EIDs.
The task of sending all the world's mapping data to these LISP-NERD
ITRs will not be a problem. By the time we have 48M EIDs, bandwidth
will be even cheaper than it is today. The update traffic is not
going to be high, since LISP mappings don't change all that often.
The whole of LISP is built on the relative stability of mappings,
with ITRs handling the moment-to-moment changes in reachability,
making their own decisions about which of multiple ETRs to tunnel the
packets to. (APT makes the same assumption. Ivip is totally
different in this regard.)
So for LISP-ALT to be chosen in preference to the simple, chunky,
fast, LISP-NERD, you must be planning to handle more than 10s of
millions of EIDs. You must be requiring the scalable routing
solution to cope with hundreds of millions of EIDs - billions or even
10 billion.
With equivalent hardware and communication costs, both APT and Ivip
can scale to a much larger number of EIDs than LISP-NERD, because
only the local query servers have to store the full mapping database
and get all the updates. Dozens or hundreds of much simpler ITRs can
work from a single local query server - so for the same or more
likely much lower total cost you can make these local query servers
more expensive, with massive RAM, multiple CPUs etc.
Its hard to put a figure on it, but lets say that with 2025
technology and communication costs, APT or Ivip could scale nicely to
handle 200M EIDs, 500M EIDs or the like.
If you are still sure that ALT is the only way to solve the routing
scaling problem, then you must be planning on handling 500M, 1B, 5B
or more EIDs.
This means you must be planning on most of those EIDs being for
individual mobile devices, because there is never going to be demand
for non-mobile EIDs in anything like these numbers.
There's only a subset of non-mobile Internet customers who have any
significant motivation to use a scalable routing solution - for the
benefits of multihoming, and/or portability between ISPs and/or
inbound traffic engineering if they are multihomed.
If the population grows to 10B people, there are only going to be a
finite number of businesses or other organisations big enough to want
any of these benefits of scalable routing. Let's assume there is one
such organisation for every 1000 people (10,000 people seems more
realistic to me).
As long as the scalable routing solution doesn't have to provide an
EID for mobile devices, then the maximum number of end-user networks
it needs to support will be 10M. Some will have two or more EIDs,
but most will only have one.
So if the scalable routing solution is not directly involved in
mobility, then you simply don't need something as complex and
problematic (initial packet delays ...) as ALT, because the
alternatives LISP-NERD, APT and Ivip will scale just fine to 10M EIDs.
Therefore, if you are convinced that LISP-ALT is the only viable
approach to scalable routing, AFAIK, you must believe:
1 - The scalable routing solution must provide an EID for each
mobile device.
AND
2 - There will be hundreds of millions or billions of these mobile
devices - enough that NERD, APT or Ivip couldn't possibly scale
to this number of EIDs, even with the technology of 2020, 2030
etc.
AND
3 - LISP-ALT will scale nicely when it does handle hundreds of
millions or billions of EIDs - and the great majority of those
EIDs are going to be for hand-held mobile devices.
As I wrote in my critique, I believe you can't make LISP work with
mobile devices as per the current I-D. I believe you could make
LISP-ALT support mobility, including for billions of EIDs, using the
TTR approach to mobility:
http://www.firstpr.com.au/ip/ivip/#mobile
I explained this over two years ago and Steve Russert and I wrote up
this nice documentation of it a year ago.
So as far as I can see, as long as you believe LISP-ALT is the only
viable solution to the scalable routing problem, in order to
establish how LISP will really work in the long-term, you need to
plan now for how LISP-ALT will handle hundred of millions of EIDs for
individual mobile devices.
- Robin
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.