[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] thoughts on the design space 1: the space
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 rrg-request@psg.com 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