On 28 Mar 2012, at 00:25, Dino Farinacci wrote: >> Hi, >> >> During wg meeting today all presentations LISP-DDT, LISP-DDT-SEC and >> LISP-DDT Database Transfer stated that this is very much like DNS. >> >> Likewise the drafts say it too: >> >> http://tools.ietf.org/html/draft-fuller-lisp-ddt-00 >> >> Conceptually, >> this is similar to the way that a client of the Domain Name System >> (DNS) follows referrals (DNS responses that contain only NS records) >> from a series of DNS servers until it finds an answer. >> >> http://tools.ietf.org/id/draft-wiley-lisp-ddtxfer-01.txt >> >> Think of a LISP-DDT query as the analog to a DNS name server (NS) >> query, and a LISP map request as the analog to a DNS address (A) >> query (LISP-DDT does not store the EID to RLOC mappings returned in a >> map request). > > What we mean is that it uses the same models as DNS. It does not use the DNS > protocol. > >> Said this I would like to ask why not use new instance of DNS with DNSSEC >> completely independent on current name resolution DNS here ? >> >> It walks like a duck .. it quacks like a duck .. it must be a duck ! > > Because it is too hard to encode long power-of-2 addresses in the DNS name > string. > >> Defining new set of records and leveraging a lot of work which went into >> (and still going) into DNS one could think would make a lot of sense rather >> then reinventing the wheel. > > And we did not want features like recursive lookups and DNSSEC, per spec. > >> If not .. if DDT approach can not be serviced by DNS architecture I think it >> would be very useful to document why. Also in the same time it would be >> great to announce plans for open source DDT support ? >
I complete agree that using DNS protocol is not the best idea, even if we proposed it in the academic paper (ref given by Olivier). First, as Dino and Olivier say, DNS as it is today, is not very good at "boundary less" prefix matching (binary encoded names). Second, because the name is of limited size in number of characters you might have troubles with long addresses with instance ID because of the way you have to encode. And the final two points, which have been pointed out by Isidor, is that (i) negative mappings are not implementable as-is in DNS and more importantly (ii) DNS caching is poor for the LISP usage as it is caches the information with the exact matching and not the wildcard reply. However, I let Isidor extending the discussion on these two points as his the guy that discovered that (so I give to Cesar what belongs to Cesar!) So what I would conclude, is that while thinking about the problem, DNS seems to be the solution, but while implementing it, it is clearly no adapted. The changes to fit DNS to the purpose are very limited but somehow fundamentals so I have the impression that the efforts necessary to map DDT to DNS are not worth w.r.t. the complexity of implementing them, the machinery to start at the IETF to add the new features needing in DNS specs, and linking DNS with all the LISP microcosm. Particularly as implementing LISP-DDT is very easy as most of the code is the same as the code used at the ITR, MR, MS and ETR, so at the end, DDT forms a nice continuous package with the rest of LISP (i.e., same encoding, same terminology, same mechanism, same code) Thank you, Damien Saucez > Dino > >> >> Many thx, >> R. >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
