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