I am reviewing this draft. Here's the first part of my review. So far I like
what I've seen, but there are a few small observations below. I'm at the
beginning of Section 4, and will continue tomorrow with the rest.
Technical:
2. Introduction
I liked how this section was written. I would like to add a little bit of
information, however. The section already talks about experimentation around
the mapping system, but like with the other documents it would be useful to
explicitly point out the areas where some further testing is needed. I presume
it is more than just the mapping system.
Note
that there may be transient conditions when the EID-prefix for the
site and locator-set for each EID-prefix may not be the same on
all ETRs. This has no negative implications.
It is of course fine to have transient conditions like this. But I'm trying
hard to convince myself that this would never have negative implications. Why
would this be the case? What if we for some reason needed to quickly add or
remove an EID prefix? Wouldn't there be a short negative implication if a
particular ETR did not yet add a new prefix, for instance?
I guess I'm wondering why you are making such an absolute statement about the lack of
implications. Maybe saying nothing or saying "This has usually no negative
implications" would be better.
Editorial:
This document describes the protocol that implements these functions.
The database which stores the mappings between EIDs and RLOCs is
explicitly a separate "module" to facilitate experimentation with a
variety of approaches. One database design that is being developed
and prototyped as part of the LISP working group work is [ALT
<http://tools.ietf.org/html/draft-ietf-lisp-15#ref-ALT>].
Others that have been described but not implemented include [CONS
<http://tools.ietf.org/html/draft-ietf-lisp-15#ref-CONS>],
[EMACS <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-EMACS>], [RPMD
<http://tools.ietf.org/html/draft-ietf-lisp-15#ref-RPMD>], [NERD
<http://tools.ietf.org/html/draft-ietf-lisp-15#ref-NERD>]. Finally, [LISP-MS
<http://tools.ietf.org/html/draft-ietf-lisp-15#ref-LISP-MS>], documents a general-
purpose service interface for accessing a mapping database; this
interface is intended to make the mapping database modular so that
different approaches can be tried without the need to modify
installed xTRs.
I think the introduction would be a good place to add some pointers to not just
ALT/MS and their competing alternatives but also to -interworking and perhaps
also -map-versioning and -multicast.
LISP can be incrementally deployed, without a "flag
day", and offers traffic engineering, multi-homing, and mobility
benefits even to early adopters, when there are relatively few LISP-
capable sites.
s/when/even when/ (sounds better to me, but I'm not a native speaker)
I think the mobility benefits could be left to another document, since there is nothing
about this in the current set of documents. I think your message about the benefits will
be stronger if you just say "traffic engineeering and multi-homing benefits".
== Outdated reference: A later version (-05) exists of
draft-ietf-karp-design-guide-02
** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275)
== Outdated reference: A later version (-09) exists of
draft-ietf-lisp-alt-07
== Outdated reference: A later version (-06) exists of
draft-ietf-lisp-lig-02
== Outdated reference: A later version (-11) exists of draft-ietf-lisp-ms-09
== Outdated reference: A later version (-08) exists of
draft-ietf-lisp-multicast-06
-- Unexpected draft version: The latest known version of
draft-iannone-openlisp-implementation is -01, but you're referring to -02.
-- No information found for draft-handley-p2ppush-unpublished-2007726 - is
the name correct?
== Outdated reference: A later version (-04) exists of
draft-ietf-lisp-map-versioning-01
These could perhaps be fixed.
== There are 8 instances of lines with non-RFC2606-compliant FQDNs in the
document.
o Source host "host1.example.abc.com" is sending a packet to
"host2.example.xyz.com", exactly what host1 would do if the site
was not using LISP.
These need to change. We should not use non-RFC2606 FQDNs. For instance,
abc.com in particular is someone else's domain. Use host1.abc.example.com or
example.com vs. example.net.
Reachability Algoriths described in Section 6.3.
typo
homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4
homogeneous
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
