Short version: How to do LISP mapping with another kind of global
query server system - DNS - and generally have the
ITRs (or their Map Resolvers) able to send the
query direct to an authoritative query server so
they get the mapping back in the reply, without any
recursive DNS lookups etc.?
It can be done, and it would be faster and more
reliable than ALT. However it wouldn't be as fast
or reliable as using local full-database query
servers - so the "initial packet delay" problem
would still exist.
Hi Noel,
In "Re: [rrg] Alternative LISP critique" you wrote:
>> CONS, ALT and now, from what you wrote in a previous message, DNS-based
>> mapping. (But I see below "LISP-TREE".)
>
> LISP-TREE is the DNS-based system.
OK - so why did the LISP team bother with CONS and ALT?
DNS was considered in November 2006, before any LISP IDs:
http://www.dinof.net/~dino/ietf/lisp2.ppt
>> If there is a single DNS server for looking up all mapping
>
> Huh?
See below.
>> then in the "vast majority of cases", it must know the mapping itself,
>> or have cached it via a recent ... lookup to an authoritative server.
>
> That is not how DNS works; DNS allows caching (at the users) of intermediate
> nodes in the resolution hierarchy. That's how you get single-RTT lookups in
> most cases - with decent fan-out in the hierarchy, the intermediate nodes are
> cached by the end-users (ITRs in this case).
The following is my speculation - the details of LISP-TREE remain to
be seen.
How will this new system structure the domains? There could be tens
of millions or billions of end-user networks and I don't know who
runs the authoritative nameservers which answer the queries.
Is there a single such nameserver for each overall DFZ prefix of EID
space (in Ivip this is a Mapped Address Block - MAB)? A MAB in Ivip
is the DITR advertises in the DFZ to attract packets for a large
blocks of address space containing the micronet space of many
(hundreds to tens of thousands) end-user networks.
LISP has no term for the same concept - the DFZ-advertised prefix
which contains many EID prefixes, typically those of thousands or
tens of thousands of different end-user networks. So I will use the
term MAB.
If so, then for a given deployment with XX MABs you would have about
2*XX authoritative DNS servers - there needs to be at least two, for
each MAB, in different places.
In order for an ITR or MR to be able to get mapping within a single
RTT, then the ITR or MR needs to already know the IP addresses of
both the authoritative DNS servers for each MAB.
I don't know how many MABs there might be in a large deployment, but
there could easily be ten thousands or whatever.
If you want to preload ITRs and MRs with two or more DNS server
addresses for each of these 10k+ MABs, then you can get single RTT
times for mapping replies, assuming the DNS server is alive and there
are no lost packets - which would be most of the time.
This is an RTT where the authoritative server which is queried could
be anywhere in the world, so it could take 0.4 seconds or so.
But that amount of preloaded or cached DNS server address stuff makes
ITRs more costly. Also you have to repeatedly preload it or update
it or let parts of it time-out and have the device reload it, on some
timeframe like a few days, so you can change the addresses of the
authoritative DNS servers for each MAB.
I think it is unrealistic to preload such large quantities of stuff
into MNs (which in LISP-MN are their own ITR) since the cost of doing
this over the (typically) wireless last link is excessive. If you
have the MN's ITR function use a MR - and the MR is preloaded with
these addresses, and maintains fresh versions of them - than that's
fine. But then you need to dynamically choose a MR which is near the
MN. If each MN only had a single MR, then this would not work very well.
The MN could be anywhere in the world, and if it happens to be in
Thailand and its MR in the UK, it is bad asking that MR to look up
mapping, since this is already a full trip around the Earth, not
counting the MR dealing with the authoritative DNS server, which may
be in Thailand. So for LISP-MN (which I argue against anyway) I
think you need the MN to be able to dynamically and securely select a
"nearby" MR, say within a 1000km or so.
If you don't preload them, then the ITR or MR will often need to do
at least one other DNS lookup to one or more other levels of server
in order to get the IP address of the authoritative server for some
MAB it has not needed to query yet.
If you don't want to preload all ITRs (or their MRs if that is what
an ITR uses) with the IP addresses of all the authoritative DNS
servers, and if you want to ensure single RTT lookups, then you need
to use a single DNS server which already has all the mapping for very
EID prefix - which is what I mentioned in the third line you quoted.
That is a centralised arrangement I understand you are keen to avoid.
>> If the end-user network has a lot of queries, due to being a popular
>> network and/or due to it having very short caching time, then there
>> needs to be a way they can pay whoever runs the DNS for their part of
>> the EID space.
>
> Seems to work now - things in google.com get a zillion hits.
OK - Google runs their own DNS servers and the addresses of them get
cached pretty rapidly by resolvers all over the world. So the burden
of lookups falls almost entirely on the Google servers and the
resolvers. That's fine.
For LISP, a smaller end-user network AAA rents their EID space from
some company YYY which owns or operates a MAB - the authoritative DNS
servers for this MAB are going to be run by, or at least will be paid
for, YYY.
So YYY bears the cost if AAA - or any other such network of the
hundreds or thousands which also rent EID space in this MAB - sets
short caching times and/or has lots of requests due to being a
popular destination of packets.
In LISP, you can't have the end-user networks running their own DNS
for mapping lookups, since they only have EID space and you can't
have ITRs depending on DNS lookups from servers which themselves
require LISP to look up.
So the authoritative DNS servers need to be run by the company which
rents out the MAB.
If an end-user network put its own prefix into the LISP system and
therefore owns an entire MAB, which it then splits up into multiple
EID prefixes, and if you want ITRs and MRs to get single RTT mapping
responses, then these DNS servers need to be on RLOC addresses and
the ITR or MR needs to be preloaded with their addresses. Then, the
end-user network pays for the large numbers of lookups and its OK.
However, this arrangement of a single end-user network per MAB is
only going to be for the larger end-user networks, such as those
which already have PI space. The only way LISP or Ivip can really
deliver on scalability is if most MABs serve the needs of hundreds,
thousands or more end-user networks.
So in general, the end-user network is not going to be running the
authoritative mapping DNS servers.
If you are going to aim for generally 1 RTT (single query, single
response) performance with LISP-TREE, then these authoritative DNS
servers are going to be handling every query. The MR may cache the
results and each ITR may cache it - but these are still going to be
busy DNS servers. Whoever runs the MAB will be charging their
end-user networks according to the DNS volume which arises from their
part of the space.
But how many MABs are there going to be? Whatever the number, you
need to preload their two or more DNS server IP addresses (all on
RLOC space) into MRs and into any ITRs which don't use MRs. Then
these devices need to keep their cached addresses fresh according to
the caching time associated with them. So if you have 10,000 MABs
and a caching time of a week, then each such ITR and MR is going to
be doing a lookup every minute. That's OK, but the next level
nameservers are going to be busy handling these queries.
So there are ways of doing this with generally 1 RTT lookups. This
is faster than ALT, and there is no "long-path" problem.
However, there's no way of anycasting the vast majority of these DNS
servers, so on average the mapping lookup is going to be some trip
across the world and back. Best to allow 200 to 300ms on average and
sometimes 400ms.
To get this improved performance, you are pushing or pulling a bunch
of stuff into MRs or ITRs which they generally won't need. That's OK
- and contrary to the aim of ALT which was not to push anything
towards anything, except perhaps from the ETR to the Map Server.
- Robin
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
