The IESG has completed a review of <draft-lear-lisp-nerd> consistent with RFC5742. The IESG has concluded that this work is related to IETF work done in WG lisp, but this relationship does not prevent publication of 'NERD: A Not-so-novel EID to RLOC Database' <draft-lear-lisp-nerd-09.txt> as an Experimental RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (http://datatracker.ietf.org/doc/draft-lear-lisp-nerd/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-lear-lisp-nerd/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary Technical Summary LISP is a protocol to encapsulate IP packets in order to allow end sites to multihome without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of EIDs to RLOCs to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of of all EID/RLOC mappings scales well to at least 10^8 entries. Working Group Summary This document is an ISE submission. From the author: This draft has a bit of an odd history. First, NERD is actually the FIRST mapping ever defined for LISP. It had to block for a REALLLY long time (some years) on a normative reference. And let's face it: doing NERD without LISP would be using ketchup/vinegar without fries/chips (pick your venue). Then it got caught in the ISE changeover, and somehow or another got left in the wrong queue somewhere along the way, and blocked for another really long time. The reason it didn't go through the working group is that the working group didn't exist at the time, and I finished the work around the time the working group was being chartered. And of course when it was chartered, there was a quite narrow charter that didn't include NERD (and to be fair, I had moved on). Document Quality See the IESG note for suggested RFC 5742 text. Personnel Brian Haberman <brian@innovationslab.net> is the responsible AD. RFC Editor Note Page 4, Section 1, 1st Paragraph: OLD: state change that occurs on routers within the default-free zone on the Internet, while enabling end sites to be multihomed. NEW: state change that occurs on routers within the default-free zone on the Internet, while enabling end sites to reach either other end-to-end. Page 11, Section 3.1, 2nd paragraph: OLD: In order to reduce storage and transmission amounts for IPv6, only the necessary number of bytes of an EID as specified by the prefix NEW: NERD assumes that EIDs stored in the database are prefixes, and therefore are accompanied with prefix lengths. In order to reduce storage and transmission amounts for IPv6, only the necessary number of bytes of an EID as specified by the prefix Page 12, Section 4.2, 1st paragraph: OLD: version of the database it has. Its first step for retrieving changes is to retrieve the current version of the database. It does NEW: version number of the database it has. Its first step for retrieving ^^^^^^ changes is to retrieve the current version of the database. It does Page 15, Section 5.2, 1st paragraph; OLD: The length of time it takes to process the database is significant in NEW The length of time it takes to transmit the database across the network is significant in Page 21, Section 7, 1st paragraph: OLD: repositories. However, for reasons mentioned in the previous section, CVS is insufficient to the task. NEW: repositories. However, for reasons mentioned in Section 5.4.1 CVS is insufficient to the task. Page 22, Section 7.1, Title: OLD: 7.1. What About DNS as a retrieval model? NEW: 7.1. What About DNS as a mapping retrieval model? IESG Note The IESG has concluded that this work is related to IETF work done in WG lisp, but this relationship does not prevent publishing.
