Hi Jari, Regarding your diagrams:
http://www.arkko.com/ietf/rrg/designspace_dataplane.jpg The Encapsulate branch is the location not just of LISP, but of APT, Ivip and TRRP. http://www.arkko.com/ietf/rrg/designspace_mappingreso.jpg Here is a fuller version of the middle and right branches: Push the full table Pull mapping as / \ needed to the ITR / \ / \ LISP-ALT / \ TRRP / \ / \ To the ITR To full database Query Servers and LISP-NERD perhaps some full database ITRs (Hybrid Push-Pull) APT Ivip LISP-NERD ITRs initiate the download of mapping updates, such as via HTTP, but this is still regarded as "push". You wrote: > DATAPLANE > ======== > > The root of the design space tree begins with the choice of > whether the intent is to do efficient routing on a flat space vs. > use a small aggregatable space and a separate identifier space. An > example solution in the former category is ROFL. Most of the > things discussed in RRG belong to the latter category. Yes, but I am wary of the use "space" in this discussion. The map-encap proposals, and Six/One Router (and the original host-based Six/One) do not create a separate namespace for identifiers vs locators. These are two different uses of an IP address, but the IP addresses are within the one namespace: Not separate namespaces: Loc-ID-separation, map-encap etc. http://psg.com/lists/rrg/2008/msg01637.html > . . . > > Pure Lisp without draft-lewis is an example of a solution that > employs encapsulation. I understand from this that you are referring to LISP without the "LISP-NAT" aspect of: http://tools.ietf.org/html/draft-lewis-lisp-interworking > . . . > > Designs that do use a mapping resolution system come in two > variants: one that always attempts to hold the entire space, and > one that runs a cache. As I depicted in the extensions to your diagram, there are important distinctions between the various map-encap proposals which are not properly covered by the above statement. LISP-NERD has every ITR gain a copy of the full database, so there is no caching whatsoever. With LISP-ALT and TRRP, all ITRs are caching ITRs, gaining their mapping information from a single global query system. (With consequent delay and reliability problems, resulting in delayed or dropped initial packets.) APT and Ivip are different from the other map-encap proposals in that they both maintain one or more local (typically within the end-user or provider network) full database Query Servers. These get the full mapping database, by full push - though the techniques for doing this for APT and Ivip are very different. APT's query servers (Default Mappers) are also ITRs. In Ivip, the full database query servers are not ITRs, but there may be one or more full databases ITRs at the same location. In both APT and Ivip, most encapsulation is done by caching ITRs and these always get their mapping quickly and reliably from a local full database query server. This means these systems have no problem with delay of initial packets, as is a problem for LISP-ALT and TRRP. Ivip has two optional elements: caching ITR functions in sending hosts (not behind NAT) and local caching query servers, between caching ITRs and the full database query servers. 3 months ago I did a detailed comparison of the map-encap proposals, involving 23 questions: Comparing LISP-NERD/ALT, APT, Ivip and TRRP http://www.firstpr.com.au/ip/ivip/comp/ There are some areas where it is not complete, particularly for TRRP, but this page lists the most important commonalities and distinguishing features. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
