Locator/ID Separation Protocol (LISP) Impact
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: "IETF-Announce" <email@example.com> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Wassim.Haddad@ericsson.com, firstname.lastname@example.org, "The IESG" <email@example.com>, firstname.lastname@example.org Subject: Document Action: 'LISP Impact' to Informational RFC (draft-ietf-lisp-impact-05.txt) The IESG has approved the following document: - 'LISP Impact' (draft-ietf-lisp-impact-05.txt) as Informational RFC This document is the product of the Locator/ID Separation Protocol Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/
Technical Summary The Locator/Identifier Separation Protocol (LISP) aims at improving the Internet scalability properties leveraging on three simple principles: address role separation, encapsulation, and mapping. LISP comprises both a tunnel-based data plane and a distributed control plane for the Internet, and requires some new functionalities, such as RLOC reachability mechanisms. The main goal of LISP is to make the Internet more scalable by reducing the number of prefixes announced in the Default Free Zone (DFZ). However, as LISP relies on mapping and encapsulation, it turns out that it provides more benefits than just increased scalability. LISP architecture facilitates routing in environments where there is little to no correlation between network endpoints and topological location. In service provider environment this use is evident in a range of consumer use cases which require an inline anchor in-order to deliver a service to a subscribers. Inline anchors provide one of three types of capabilities: o enable mobility of subscriber end points o enable chaining of middle-box functions and services o enable seamless scale-out of functions Working Group Summary There was no major controversy. The WG had a debate on the impact of cache size, i.e., cache performance, control overhead and scalability of control plane (related to results published in one particular research paper [CCD12]), which triggered two revisions of the document. Document Quality Are there existing implementations of the protocol? Yes, there are multiple implementations of LISP (at least 3) Have a significant number of vendors indicated their plan to implement the specification? At least one major vendor (Cisco) has already implemented LISP specification. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? Review by Ross Callon triggered two revisions of the document but without major changes. Reviewer was satisfied with version 03 of the document If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document does not require a MIB doctor Personnel Wassim Haddad is the document shepherd. The responsible area director is Deborah Brungard.