Hi Damien-
Thanks for catching the typos. I few comments on your comments:
> > 7.4. Just Enough Security
> >
> > How much security to have is a complex issue. It's relatively easy
> > for designers to add good security, but much harder to get the users
> > to jump over all the hoops necessary to use it. LISP has therefore
> > adopted a position where we add 'just enough' security.
> >
> > The overall approach to security in LISP is fairly subtle, though,
> > and is covered in more detail elsewhere (in [Architecture], Section
> > "Security").
>
> I don't agree with this approach.
Can you be more specific about what you don't like and suggest an alternative?
> > 10.1. Internetworking Mechanism
> >
>
> interworking
I might re-title this section "Interworking with non-LISP systems"
> > 11.2. Replacement of ALT with DDT
> >
> > As mentioned in Section 9.2, an interface is provided to allow
> > replacement of the indexing subsystem. LISP initially used an
> > indexing system called ALT. [ALT] ALT was relatively easy to
> > construct from existing tools (GRE, BGP, etc), but it had a number of
> > issues that made it unsuitable for large-scale use. ALT is now being
> > superseded by DDT.
> >
> > As indicated previously (Section 9.5), the basic structure and
> > operation of DDT is identical to that of TREE, so the extensive
> > simulation work done for TREE applies equally to DDT, as do the
> > conclusions drawn about TREE's superiority to ALT. [Jakab]
> >
> > {{Briefly synopsize results}}
>
> DDT builds a hierarchy of nodes and, by default, every request has
> to traverse the entire hierarchy from the root to a leaf (i.e., a MS).
This is not entirely correct. Once a DDT Map Resolver's (MR's) referral
cache has been populated, it does not need to send all requests to the
root; any request for a sub-tree of the EID space which is known in the
referral cache is sent directly to the MS's for that sub-tree.
> This is somehow similar to LISP+ALT where requests have to traverse the
> ALT topology to reach a MS and finally the ETR. However, an
> important distinction has to be made. Indeed, with ALT, the mapping
> does not follow the same logical path than the request.
I don't understand these sentences.
> As a result, the MR has no way to discover the topology and is not able
> to cache mapping for subsequent ITR requests.
This is not entirely correct. An MR does not cache EID-to-RLOC mappings
themselves but it does cache referrals that list the DDT Map Servers for
every part of the EID space that it queries. The MR thus discovers the
EID space topology and stores that information in its referral cache.
> On the contrary, MR in DDT works in a recursive way: the MR first queries
> the root that gives a referral to one of its child and so on until the
> address of a MS is known. At this stage, the MR can cache the referral
> such that subsequent request do not have to traverse the full hierarchy.
> [Jackab] shows by the mean of simulations with real packet trace, that it
> is possible to construct the hierarchy such that most of the requests are
> sent close to the leaves in the hierarchy, significantly reducing the
> mapping resolution time.
This is mostly correct but confusing, your use of the term "recursive"
particularly so; a DDT MR explores the EID topology (DDT) using an
interactive process. From the perspective of an ITR that sends a request
to a a DDT MR, the process appears to be recursive (just as the iterative
DNS resolution process appears recursive to a host that sends a DNS request
to a caching resolver); that does not mean that the process is recursive.
Your mentioning of DDT MR caching in this paragraph contracts the
statements you made earlier about having to start at the root; again,
quite confusing.
> > 11.2.1. Why Not Use DNS
> >
> > One obvious question is 'Since DDT is so similar to DNS, why not
> > simply use DNS?' In particular, people are familiar with the DNS,
> > how to configure it, etc - would it not thus be preferable to use it?
> > To completely answer this would take more space that available here,
> > but, briefly, there were two main reasons, and one lesser one.
> >
> > First, the syntax of DNS names did not lend itself to looking up
> > names in other syntaxes (e.g. bit fields). This is a problem which
> > has been previously encountered, e.g. in reverse address lookups.
> > [RFC5855]
> >
> > Second, as an existing system, the interfaces between DNS (should it
> > have been used as an indexing subsystem for LISP) would not be
> > 'tuneable' to be optimal for LISP. For instance, if it were desired
> > to have the leaf node in an indexing lookup directly contact the ETR
> > on behalf of the node doing the lookup (thereby avoiding a round-trip
> > delay), that would not be easy without modifications to the DNS code.
> > Obviously, with a 'custom' system, this issue does not arise.
> >
> > Finally, DNS security, while robust, is fairly complex. Doing DDT
> > offered an opportunity to provide a more nuanced security model.
> > (See [Architecture], Section "Security" for more about this.)
>
> will see with time, but I am not sure that security will really be
> easier with DDT.
Maybe "easier" is the wrong word, but given that ALT does not define any
security mechanism (it simply assumes the use of whatever is available
with BGP), the explicit description of how security works with DDT would
seem to be "easier"/"better" to me.
--Vince
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
