Short version: Dino suggested altering LISP ALT so the Map
Resolvers fully cache all the mapping they
request. He also suggested each ITR download
a copy of its MR's cache at boot time.
This only provides marginal improvements over
LISP-ALT or LISP-CONS, since there still needs
to be a global query server system, which is
slow and unreliable. This means that some
initial packets will still be dropped or be
delayed for so long that they are useless or
worse than useless when they arrive.
Making these MRs (which are local to the ITRs
they serve) full database would solve the
show-stopper problems of LISP-NERD and of
LISP-CONS or LISP-ALT. There would be no
need for a CONS or ALT network and there would
be no problem with dropped or delayed initial
packets. The scaling problems of NERD would
be eliminated.
The result - LISP with full-database MRs -
would resemble APT.
By distributing mapping updates to the MRs
in real time, the system would somewhat
resemble Ivip. In such a system the ITRs
and ETRs can be much simpler, and the
mapping information simpler and more compact
since there is no need for the ITRs, or MRs,
to choose between different ETR addresses.
The end-user network itself would be
responsible for making this choice in real
time, which makes the system much more flexible
and better able to handle outages according
to the actual circumstances. The end-user
networks would typically contract a specialised
company to probe ETR reachability and control
the mapping of their EIDs accordingly.
(A potential disadvantage of this over LISP
or APT is that LISP or APT may be able to
cope better with a situation where each ETR
is reachable from only a subset of the Net.)
Hi Dino,
In the NERD thread, you wrote:
> How about this:
>
> (1) Have an ITR, when it boots up, ask its map-resolver for all mappings
> it might have cached.
> (2) It may not eliminate all Map-Requests but maybe a large number of them.
> (3) Does require the map-resolver to be a caching system.
Assuming that you are making these changes to LISP-ALT (or LISP-CONS)
this doesn't alter the fact that the Map-Resolvers (MRs) rely on a
mapping distribution system which is distributed and global - and
therefore complex, slow and unreliable.
It is reasonable to assume that each ITR will be quite close to its
one or more MRs. So these are *local* MRs - local query servers. In
this setting, there's no need for ITRs to cache any more mapping
information than they need for the packets they are handling, since
they are close enough to their one or more local MRs to be able to
get any mapping which is already cached in the MR within a few tens
of milliseconds.
I think it is fair to assume that holding an initial packet for a few
tens of milliseconds, probably up to 100 ms or so, will not cause
significant impact on any known protocol other than perhaps ping and
traceroute when compared to today's IDR system. Assuming the source
and destination hosts are both on EID addresses, it would cause a
one-off extension in ping time for the first ping packet and probably
too for the ICMP packet which it generates. Traceroute would take a
little longer assuming the source was on an EID address, and assuming
the routers were not.
If you take LISP-NERD and:
Add caching MRs.
Make the ITRs caching instead of full database.
then the result in no way resembles NERD.
If you take LISP-CONS or LISP-ALT or whatever and:
Add caching MRs.
then you arguably still have CONS or ALT or whatever.
To this, you could have three kinds of ITR behaviour:
A - Cache only the mapping needed by the ITR's
traffic.
B - (As you suggested) have the ITR cache the full
contents of its (one or more?) MR's caches at
boot time, and then cache only the mapping it
needs for its traffic.
C - Constantly receive updates from the MR, so the
ITR's cache contents are identical to the MR's.
In A and B, the ITR still needs to query the MR for mapping it
doesn't have. Its just that in the case of B, by storing a finite
amount of mapping at boot time (presumably mapping which is more
likely to be used by the ITR than would be a the average for the
whole mapping database) you would reduce the need for the ITR to
query the local MR. However, this requires a large transfer of
information to each ITR at boot time, which is arguably more trouble
than it is worth.
With C, the ITR generally makes less requests to the MR, since it
is kept up to date with the MR's full mapping cache, which is a
function of the activities of all the ITRs which use this MR. So as
with B, you reduce the number of ITR to MR requests, at the expense
of a large flow of mapping updates to each ITR, which must all be
stored - and most of those mapping updates will be of no use to a
single ITR.
In all these cases, A, B or C, you have created either:
ALT with caching MRs.
NERD with the full database internal query server of each
NERD ITR replaced by a caching query server which relies on a
local caching MR.
In all these cases, you still have ALT's global query server system
and you still have delayed or dropped initial packets. You will have
fewer delayed or dropped initial packets than the current ALT system,
in which MRs do not cache. However, you will still have this problem
- I think to a degree which makes such a scheme a non-starter for
voluntary adoption.
The performance differences between A, B and C are inconsequential, I
think, since all three will enable the ITR to send any packet within
a few tens of milliseconds, as long as the MR has the mapping cached.
The greater MR -> ITR mapping traffic options of B and C only reduce
this short delay time. I think A is just as good, since the MR is
close to the ITRs and the system A ITR can quickly and reliably query
the MR. B and C reduce the amount of query traffic each MR handles,
but require the MRs to pump out their full mapping database: B to
each ITR at its boot time and C at this time, and with a continual
stream of updates to each ITR as well.
Compared to ordinary ALT, the only substantial benefits you gain by
introducing caching MRs with systems A, B or C, are:
1 - When an ITR X requires mapping for an EID which the MR has,
it gets it in a few tens of milliseconds from the local MR.
This only occurs due to another ITR which the MR serves having
requested mapping for this EID within the caching time.
2 - To the extent that this does occur, this reduces load on the
ALT network and its Map Servers.
3 - To the extent this does occur, it essentially eliminates the
lost or unusably delayed initial packet problem.
However, these benefits only occur when another ITR served by this MR
has recently requested mapping for this EID.
Here is another approach: full database MRs for LISP:
You can take your proposal and make the MRs full database. Or you
can take NERD, take the full database query server out of each ITR
and replace it with a caching query server. The caching query server
talks to one or more full database MRs.
Each such MR has the same storage and mapping update traffic
requirements as a single NERD ITR, but it serves the needs of many
(dozens to thousands?) of ITRs, which are now caching ITRs. (Of
course, you could co-locate a full database MR in an ITR, and so make
this device serve multiple nearby caching ITRs too.)
As I wrote here:
Re: NERD - comparison with other schemes
http://www.ietf.org/mail-archive/web/rrg/current/msg05281.html
The LISP mapping systems occupy two extremes of a spectrum of answers
to the question: "How many devices store the full mapping database?".
On one end is NERD: "Hundreds of thousands or millions - every ITR."
On the other end, CONS and ALT: "None."
Making LISP MRs full database is the most obvious enhancement to NERD
since it fixes NERD's primary problem of poor scaling with large
mapping databases.
A full-database MR version of LISP should probably have a name
different from NERD.
A full-database MR version of LISP has nothing to do with CONS or
ALT, since there would be no need for the CONS or ALT networks. All
that is needed is a way the MRs can get their mapping information.
NERD does this, for each ITR, by downloading updates from one or more
centralised or somewhat centralised servers, such as by HTTP.
A full-database MR version of LISP would be a vast improvement on
NERD, CONS or ALT.
It would eliminate the primary objection to NERD - bad scaling. It
would eliminate the primary objections to CONS and ALT:
1 - Dropped or delayed initial packets.
2 - The need for a global query server network, which is inherently
slow, unreliable and costly.
This approach to LISP would resemble APT.
My understanding is that APT distributes its mapping to all its local
full database query servers (Default Mappers - DMs) via the data
percolating around between the DMs in all the ISPs which form an "APT
cloud". This is a set of ISPs which share physical links, since the
data is percolated around on the back of a BGP system (either the
main BGP system or a similar one, just for APT updates - I can't
recall exactly how).
I have suggested APT be altered to allow tunneled links between ISPs
for the purpose of distributing mapping updates. This would mean all
ISPs would be part of a single "APT cloud". This would enable APT to
reliably handle EIDs spanning less IP addresses than the 256 IP
address granularity of today's IPv4 BGP system (which I assume is
unlikely to be reduced).
By keeping NERD's ITR/MR initiated HTTP download system, you would
avoid the relatively slow, fully distributed, nature of APT's mapping
distribution system and replace it with a somewhat centralised, much
simpler, arrangement where a limited number of servers, or
distributed systems of servers, are the authoritative source of all
mapping information.
This approach to LISP, like APT, would still require the mapping to
contain multiple ETR addresses so the individual ITRs (or DMs in APT,
which actually make the decision of which ETR to use) still need to
figure out for themselves which ETR to use when one of them becomes
unreachable.
You could simplify the mapping data, reducing it to a single ETR
address, by taking this decision process out of the ITRs (or for APT,
out of the DMs) and by making the decision a real-time responsibility
for the end-user network whose EID this is.
To do this, you would need to have an essentially real-time (a few
seconds, for instance) mapping distribution system, with the updates
going to all the full-database MRs (or for APT, DMs). The end-user
network would probably contract out the real-time control of its
mapping to a specialised company, with a robust network, since at the
time you most need the mapping changes, the end-user network's
network is likely to be suffering connectivity problems.
Ivip is one way of doing this - local full-database query servers
with real-time mapping distribution and so much simpler ITRs and
ETRs, since the ITRs don't need to make any decisions about which ETR
to use.
The major distinctions between NERD, APT, Ivip and LISP-ALT are
listed at:
http://www.firstpr.com.au/ip/ivip/comp/
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
