[lisp] AD review of draft-ietf-lisp (part 1)

[Jari Arkko <[e-mail]>]

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