Last Call Review of draft-ietf-lisp-deployment-08
review-ietf-lisp-deployment-08-genart-lc-carpenter-2013-07-10-00

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-lisp-deployment-09.txt
Reviewer: Brian Carpenter
Review Date: 2013-07-10
IETF LC End Date: 2013-07-15
IESG Telechat date:

Summary:  Almost ready
--------

Comments:
---------

I was assigned to review -08, but -09 came out during Last Call.

Issues:
-------

The draft states in its Introduction that it "is expected to evolve as LISP
deployment progresses, and the described scenarios are better understood or
new scenarios are discovered." The desire to freeze a version of the draft
as an RFC is understandable, but shouldn't the title and Abstract clearly
indicate that it's a snapshot (and genuinely a request for comments)?

In general the draft is clear and well written. If you believe that there
are sufficient incentives for Tier 3 providers and large sites to deploy
an experimental protocol such as LISP, the discussion is useful. However,
I am disappointed by the limited discussion of scalability. In particular,
the incentives to deploy P-ITRs and to announce routes to them will become
a critical issue at the half-way stage between early transition (LISP is a
minority solution) and late transition (LISP is the majority solution).
According to RFC 6832, P-ITRs scale either because "aggregate routes might
be selectively announced" or because "the same address might be announced
by multiple Proxy-ITRs in order to share the traffic." I really expected
the deployment draft to discuss this issue in more detail. As I believe
has been said before, these issues are very similar to the issues facing
the operators of a 6to4 forward or return relay. We have experimental
evidence there that altruism doesn't work and the incentives to "donate"
connectivity are insufficient. The analogy isn't perfect, but the underlying
question is similar - what is the incentive for a particular operator to
offer P-ITR service for a particular bunch of EID prefixes, when the
clientele might be up to half the Internet, depending on who chooses to
propagate the routes?

The Security Considerations are minimal. I wonder if draft-ietf-lisp-threats
identifies threats for each scenario described in draft-ietf-lisp-deployment?
If not, the statement "Security implications of LISP deployments are to be
discussed in separate documents." is rather optimistic.