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. LISP (Locator/ID Separation Protocol) is a protocol supporting separating the two functions of IP addresses: node identification and node addressing. It is important in scenarios (like we have today) where organizations own many disjoint ranges of the IP address space causing routing tables to be much bigger than they would have to be if every organization owned a single contiguous space. It also has potential to allow nodes to keep the same IP address for purposes of identification even when their address for purposes of routing changes due to mobility or network reconfiguration. It uses LISP-capable border routers to encapsulate packets and address them to LISP-capable border routers on the other side of the "core Internet". This is an introductory document, where there at least nine other documents specifying details of components used to implement the needed mechanisms. There is a security considerations section, which focuses on a class of denial of service attacks. There are presumably security considerations sections in the other documents, including one that focuses entirely on security, so it is not necessary that all security issues be brought up here. That said, I think that if you were to write an "introduction to security considerations", there are more important ones than the DoS threat. in particular, as a routing protocol care must be taken to make sure a bad actor cannot attract someone else's traffic with mechanisms like those we are trying to address with BGP security. Much of the routing information is maintained in a database "like DNS". If it *were* DNS, DNSSEC could be used to address the integrity issues. If it is home grown, some equivalent mechanism will be necessary.  Why not use DNS? Non-Security comments: I assume this document is intended to introduce LISP, and so would logically be the first document that someone wanting to learn about LISP would read. It therefore should point to the other LISP documents for more details but should not depend on them for the purpose of understanding this one. There are a number of concepts that I believe one would have to understand in order to understand LISP and being reading the other documents in the series. I would expect, therefore, that they would be in this document but I could not find them. (If my assumption is incorrect, and there is some other document that should be read before this one, that should be mentioned in the introduction). Section 2. Having no terms defined and referring to reader to check any of nine associated documents is not user friendly. It would be nice if at least one of the documents defined all the terms that were used in more than one document so there would be one place to go for definitions not included in the document being read. EIDs and RLOCs have the same length, appearing to be either IPv4 or IPv6 addresses or perhaps from some other space. Fundamental to understanding LISP is understanding whether they reuse the same values or whether they partition the space into EIDs and RLOCs. This is particularly tricky (and therefore important) in the case of IPv4 addresses, since that space is very densely filled and there would not be room to divide it into two spaces both large enough to accommodate the Internet. Is the expectation that EIDs would be taken from a reserved range (likely the 10.*.*.* range), in which case growth of LISP will be severely constrained during its coexistence phase, or alternately will EIDs use the entire range, in which case it will be difficult or impossible to make LISP nodes interoperate with non-LISP nodes? In a related question, section 3.2 says that EIDs will typically be retrieved from DNS. Is the intent that they be retrieved from A or AAAA records, or from new record types created for LISP. For a LISP node opening a connection to a non-LISP node, will its DNS lookup return a different value than when a non-LISP node is opening a connection to a non-LISP node? How is that made to happen? More detailed questions (that should probably be addressed in order to understand the architecture): Section 3.2 Page 7 item 3: It says that two locators are returned. Is this just an example where there also might only be one locator or there might be 10, or is it always two? If an example, is there some maximum number of addresses (or at least some maximum number likely to be used)? Section 3.3.1: When the UDP header is created, what is used as the source port? Does the decapsulating router (ITR) ignore the outer source IP address and the outer source port, or is there some sort of check done on that information or state established? Typos: Page 9: "An RTR can be thought as a" -> "An RTR can be thought of as a" Page 21: "informations" -> "information" Page 25: "are note used" -> "are not used"