I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This draft describes LISP deployment scenarios. It represents current thinking and is expected to change (I guess be obsoleted / replaced?) as more experience is gained with deployment.

Summary: I'm not sure what to do here.

The document is very well written, and the authors seem to have taken care to consider the implications of various deployment scenarios. 
In spite of knowing very little about LISP I found the document to be accessible and easily understood. It clearly lays out the considerations for different deployments, and provides some guidance as to how to select.


However, the security considerations section simply says:
"Security implications of LISP deployments are to be discussed in
   separate documents.  [I-D.ietf-lisp-threats ] gives an overview of
   LISP threat models, while securing mapping lookups is discussed in
   [I-D.ietf-lisp-sec]."

This is a deployment document, and so this may be perfectly acceptable; the "separate documents" may completely cover everything. Or not.
I am unclear if the authors mean that I-D.ietf-lisp-threats and I-D.ietf-lisp-sec cover all security considerations, or if the implication is that there will be other documents that cover the security implications. 


http://i.imgur.com/5rTHfRs.jpg





Section 2.4.  "Inter-Service Provider Traffic Engineering" says:
"Failure to follow these recommendations may lead to operational and security issues when deploying this scenario."
I think that a (short) explanation of what the security issues are if you don't follow the recommendations would be nice.


Nits:
Section 4.2:
"For more details on P-ETRs see the [RFC6832] draft." -- I think that this could be better worded as "For more details on P-ETRs see [RFC6832]" (think this was written while RFC6832 was still a draft).

ID NITs complains about use of RFC2119 language ("It is NOT RECOMMENDED for deployment"), but no RFC2119 reference / boilerplate.
I'm scraping the bottom of the barrel here, 'tis well written..

--
It is impossible to sharpen a pencil with a blunt axe.  It is equally vain
to try to do it with ten blunt axes instead.
    --  E.W Dijkstra, 1930-2002