Subject: [lisp] DDT vs DNS

From: Robert Raszuk <[email-masked]>
Date: Tue, 27 Mar 2012 21:51:45 +0200

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).

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 !

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.

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 ?

Many thx,
R.

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 27 Mar 2012 22:08:32 +0200

Robert,
> LISP-DDT Database Transfer stated that this is very much like DNS.

See also the original LISP-TREE paper for more details on the benefits
of such a mapping system
http://inl.info.ucl.ac.be/publications/lisp-tree-dns-hierarchy-support-lisp-mapping-system
> would be great to announce plans for open source DDT support ?

One of the issues that I see in reusing the DNS is the LISP would have
to support the (very old) history of DNS and the various protocol
extensions. Bitlabel would seem the best way of encoding mappings, but
bitlabels have been deprecated http://tools.ietf.org/html/rfc3363 which
means that LISP could not simply reuse existing DNS servers. If there
are modifications required to the DNS, then seems more realistic to
avoid using an already overloaded protocol like the DNS.

Although I was initially in favor of reusing the DNS, I changed my mind...

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 27 Mar 2012 22:24:44 +0200

Hello Olivier,

Let me clarify.

I am not suggesting to reuse existing DNS servers at all. I am just 
suggesting (well not even that .. trying to understand why this is bad 
idea) to reuse existing DNS/DNSSEC code on completely opaque to the DNS 
and DNS infrastructure deployment.

Effectively to fully follow LISP DDT principals however reused existing 
DNS bind with all of the latest enhancements.

Best regards,
R.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 Mar 2012 15:25:51 -0700

>   query (LISP-DDT does not store the EID to RLOC mappings returned in a

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 ?
> 

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 ?

Dino

> 
> Many thx,
> R.
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Damien Saucez <[email-masked]>
Date: Wed, 28 Mar 2012 01:09:06 +0200

>> 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 sup…

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

---

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 28 Mar 2012 06:25:05 +0000

Nifty idea, as a dns operator that would make it easy for us :)

Having said that, dns is useful as a common point of reference to help explain ddt but has significant enough differences (and the joy of dodging legacy baggage) to make a separate protocol a sensible option.

----- Original Message -----
From: Robert Raszuk [mailto:[email-masked]]
Sent: Tuesday, March 27, 2012 03:51 PM
To: [email-masked] <[email-masked]>
Subject: [lisp] DDT vs DNS

Hi,

    Conceptually,

Many thx,
R.

---

From: Michael Hoefling <[email-masked]>
Date: Wed, 28 Mar 2012 09:10:48 +0200

As far as I got it, LISP-DDT is based on the ideas of LISP-TREE, which 
is based on DNS. Just in case you're not familiar with LISP-TREE, take a 
look on this paper for more information:
http://inl.info.ucl.ac.be/system/files/2010-jakab-jsac-lisp-tree.pdf

Regards,
Michael

Am 28.03.2012 08:25, schrieb Wiley, Glen:
> To: [email-masked]<[email-masked]>

-- 
Dipl.-Inform. Michael Hoefling, M.Sc.
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70507, fax: (+49)-7071/29-5220
mailto: [email-masked]
http://kn.inf.uni-tuebingen.de/staff/hoefling

---

From: Isidor Kouvelas <[email-masked]>
Date: Wed, 28 Mar 2012 10:38:06 +0300

> to Cesar what belongs to Cesar!)

Olivier and Damien have accurately summed up the findings of the DNS 
based mapping system prototype we worked on.

- When matching a delegation hole the DNS NXDOMAIN answer does not 
include information on the hole that was matched in the zone file. This 
information is required by the resolver to return the negative map-reply 
to the ITR.

- The DNS answer contains the full name that was queried as well as the 
SOA prefix. It does not contain the name of the wild-card entry in the 
zone file that was matched by the query and that points to the 
map-servers. That entry represents the prefix being delegated to the 
map-server and is what ideally would be cached by the resolvers.

- Encoding XEID prefixes would be best done with the DNS bitlabel 
extensions that have been deprecated and removed from some (most?) 
implementations.

There are ways around all of the above but not without modifying the DNS 
server / resolver code.

Isidor

---

From: Darrel Lewis <[email-masked]>
Date: Fri, 30 Mar 2012 04:44:07 -0700

> LISP-DDT Database Transfer stated that this is very much like DNS.
<snip>

This thread has documented some of the reasons why the authors decided to develop DDT instead of re-using DNS (documented in LISP-TREE).  In addition to these, the DDT authors felt that operational experience with LISP+ALT (which re-used BGP and GRE for distributing EID Prefixes) showed that re-using another protocol, while inheriting many useful features, also brought in many un-needed features which added bloat to the implementation and operational complexity to the network. 

<snip>
> 
> If not .. if DDT approach can not be serviced by DNS architecture I think it would be very useful to document why.

Other mapping systems have been explored before with LISP, to various levels of maturity.  (EMACS, CONS, etc).  Its my understanding that the LISP-TREE draft will be updated to reflect the work done to date, which should include the limitations of this approach.

> Also in the same time it would be great to announce plans for open source DDT support ?

All are welcome to contribute to the Open Source LISP (the scope of which includes the mapping system) effort.  More information can be found at http://www.openlisp.org/).

Regards,

-Darrel

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 Mar 2012 15:07:12 +0200

Hi Darrel,

My point was not to say that DDT is a wrong approach. I am just looking 
from user POV and wanted to see why DNS infra (which is relatively easy 
to reuse) would not offer me the off the shelf open source tools to 
build a mapping plane. Do you really expect that every SP potentially 
interested in LISP will develop it's own mapping plane code ?

If you look at bigger picture we are right there in the IETF with the 
need for inter-as globally scoped information distribution. Some push to 
use BGP new SAFI as an overlay for CDNI, some put more data onto 
existing DNS, yet some develop new point protocols (DDT). That clearly 
proves to me the need to have a common service bus .. perhaps reusing a 
lot of BGP attributes however allowing very easy flexibility for new 
types of information transport without need to go to IETF and each time 
argue for 2 years to justify new SAFI.

Openlisp as far as I see have no mapping plane code available. I guess 
the ALT failed as it would have to include full BGP. Maybe with DDT you 
will have more luck. Contrary openlisp.org has ITR code which 
practically I would rather have hardware based. Mapping plane is x86/vm 
appliance based so it would be much more important to download and run 
(if one needs LISP).

Last I was not clear from any presentations how DDT would inter-operate 
with ALT. Well perhaps there is no issue with migration yet however as 
we are at the experimental mode and it would be great to see how 
easy/difficult is to migrate one mapping plane to the other.

Best regards,
R.

>> During wg meeting today all presentations LISP-DDT, LISP-DDT-SEC
>> and LISP-DDT Database Transfer stated that this is very much like
>> DNS.
>>
> <snip>
>
> This thread has documented some of the reasons why the authors
> decided to develop DDT instead of re-using DNS (documented in
> LISP-TREE).  In addition to these, the DDT authors felt that
> operational experience with LISP+ALT (which re-used BGP and GRE for
> distributing EID Prefixes) showed that re-using another protocol,
> while inheriting many useful features, also brought in many un-needed
> features which added bloat to the implementation and operational
> complexity to the network.
>
> <snip>
>>
>> think it would be very useful to document why.
>
> Other mapping systems have been explored before with LISP, to various
> levels of maturity.  (EMACS, CONS, etc).  Its my understanding that
> the LISP-TREE draft will be updated to reflect the work done to date,
> which should include the limitations of this approach.
>
>
> All are welcome to contribute to the Open Source LISP (the scope of
> which includes the mapping system) effort.  More information can be
> found at http://www.openlisp.org/).
>
> Regards,
>
> -Darrel
>

---

From: Damien Saucez <[email-masked]>
Date: Fri, 30 Mar 2012 15:41:57 +0200

> All are welcome to contribute to the Open Source LISP (the scope of which includes the mapping system) effort.  More information can be found at http://www.openlisp.org/).

We are working on an open source implementation of DDT (to be later added to OpenLISP) that we
are still testing and improving. Feel free to contact us if you are willing to contribute.

Best regards,

Damien Saucez

---

From: Darrel Lewis <[email-masked]>
Date: Fri, 30 Mar 2012 06:57:11 -0700

Hi Robert,

On Mar 30, 2012, at 6:07 AM, Robert Raszuk wrote:

> Hi Darrel,
> 
> My point was not to say that DDT is a wrong approach. I am just looking from user POV and wanted to see why DNS infra (which is relatively easy to reuse) would not offer me the off the shelf open source tools to build a mapping plane. Do you really expect that every SP potentially interested in LISP will develop it's own mapping plane code ?

No of course not, I'm sorry if I gave that impression.  I expect (hope?) there will be implementations from a variety vendors, as well as open source implementations.

> 
> If you look at bigger picture we are right there in the IETF with the need for inter-as globally scoped information distribution. Some push to use BGP new SAFI as an overlay for CDNI, some put more data onto existing DNS, yet some develop new point protocols (DDT). That clearly proves to me the need to have a common service bus .. perhaps reusing a lot of BGP attributes however allowing very easy flexibility for new types of information transport without need to go to IETF and each time argue for 2 years to justify new SAFI.

Personally, I like the fact that there are a wide set of solutions to a variety of different problems.  But I can see how others might find the current environment an opportunity for consolidation.

> 
> Openlisp as far as I see have no mapping plane code available.

I have heard from people here in Paris that they are on open source DDT Mapping system code, and I was told that they welcome contributions. :-)

> I guess the ALT failed as it would have to include full BGP.

I don't think the ALT failed per say (though, admittedly, I'm biased :-) ). But I do think it was found to have some properties that operators found costly and we wanted to do better.  As I said in my earlier message, a part of that cost was the use of a protocol that wasn't explicitly designed for LISP.  The original charter of the LISP WG explicitly encouraged further mapping system experimentation, something the authors of LISP+ALT have been enthusiastically working on.

> Maybe with DDT you will have more luck. Contrary openlisp.org has ITR code which practically I would rather have hardware based. Mapping plane is x86/vm appliance based so it would be much more important to download and run (if one needs LISP).
> 

I agree that it makes sense to have solutions in the mapping plane that can be independent of hardware forwarding implementations.

> Last I was not clear from any presentations how DDT would inter-operate with ALT. Well perhaps there is no issue with migration yet however as we are at the experimental mode and it would be great to see how easy/difficult is to migrate one mapping plane to the other.

We spent some time talking about interoperability and decided that it was less costly to migrate directly to DDT. We migrated the LISP Beta Network (www.lisp4.net) from LISP+ALT to LISP-DDT a couple of weeks ago.  The migration went smoothly, and we've gotten a good bit of feedback on the protocol that the authors hope to reflect in future versions of the draft.  One thing to note is that the sites did not notice the change, since xTRs interface to the mapping system with Map-Resolvers and Map-Servers, and those interfaces did not change.

We have recently added a second, independent to the Beta Network, lisp service provider network to the LISP-DDT mapping system, and have plans for connecting other LISP networks in the coming weeks.  For more information about the ongoing deployment of LISP-DDT,  you can check out ddt-root.org.

Regards,

-Darrel