Is there (or could there be) a link outside web page that could contain auxiliary material, such as research papers, that may be produced as the work progresses ?
Regards Marshall On Thu, Dec 1, 2011 at 8:26 PM, Terry Manderson <[email protected]> wrote: > After a receiving the suggestions from Yakov and John, emailing some ADs, > the draft charter is as follows: > > Please review, and highlight any areas missed. I'd like to close this off by > next Friday (9th Dec), and pass to our AD. > > The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) > rekindled interest in scalable routing and addressing architectures for > the Internet. Among the many issues driving this renewed interest are > concerns about the scalability of the routing system and the impending > exhaustion of the IPv4 address space. Since the IAB workshop, several > proposals have emerged which attempt to address the concerns expressed > there and elsewhere. In general, these proposals are based on the > "locator/identifier separation". > > The basic idea behind the separation is that the Internet architecture > combines two functions, routing locators, (where you are attached to the > network) and identifiers (who you are) in one number space: The IP > address. Proponents of the separation architecture postulate that > splitting these functions apart will yield several advantages, including > improved scalability for the routing system. The separation aims to > decouple locators and identifiers, thus allowing for efficient > aggregation of the routing locator space and providing persistent > identifiers in the identifier space. > > LISP supports the separation of the IPv4 and IPv6 address space > following a network-based map-and-encapsulate scheme (RFC 1955). In > LISP, both identifiers and locators are IP addresses. In LISP, > identifiers are composed of two parts: a "global" portion that uniquely > identifies a particular site and a "local" portion that identifies an > interface within a site. The "local" portion may be subdivided to > identify a particular network within the site. For a given identifier, > LISP maps the "global" portion of the identifier into a set of locators > that can be used by de-capsulation devices to reach the identified > interface; as a consequence a host would typically change identifiers > when it moves from one site to another or whenever it moves from one > subnet to another within an site. Typically, the same IP address will > not be used as an identifier > and locator in LISP. > > LISP requires no changes to end-systems or to most routers. LISP aims > for an incrementally deployable protocol. > > A number of approaches are being looked at in parallel in other > contexts. The IRTF RRG examined several proposals, some of which were > published as IRTF-track Experimental RFCs. > > The LISP WG is chartered to work on the LISP base protocol and any items > which directly impact LISP including any base protocol changes required to > enable VPN and mobile topologies (precise operational definitions of > these topologies should be left for IETF WGs focused on these technologies). > The working group will encourage and support interoperable LISP > implementations as well as defining requirements for alternate mapping > systems. The Working Group will also develop security profiles for LISP > and the various LISP mapping systems. > > It is expected that the results of specifying, implementing, and testing > LISP will be fed to the general efforts at the IETF and IRTF (e.g., the > Routing Research Group) that attempts to understand which type of a > solution is optimal. The LISP WG is NOT chartered to develop the final > or standard solution for solving the routing scalability problem. Its > specifications are Experimental and labeled with accurate disclaimers > about their limitations and not fully understood implications for > Internet traffic. In addition, as these issues are understood, the > working group will analyze and document the implications of LISP on > Internet traffic, applications, routers, and security. This analysis > will explain what role LISP can play in scalable routing. The analysis > should also look at scalability and levels of state required for > encapsulation, decapsulation, liveness, and so on as well as the > manageability and operability of LISP. > > > Goals and Milestones > > > Jun 2012 Forward draft-ietf-lisp-mib to the IESG > > Jun 2012 Forward draft-ietf-lisp-sec to the IESG > Jun 2012 Forward to the IESG an operational document which should > include cache management and ETR synchronization > techniques (draft-ietf-lisp-deployment). > Dec 2013 Publish an example cache management specification. > Dec 2013 Forward to the IESG an evaluation of the security threat to > cache maintenance (draft-ietf-lisp-threats) > Dec 2013 Forward to the IESG a document addressing the areas which > require further experimentation. > Jun 2014 Evaluate the applicability and coverage for LISP from a > reuse of SIDR technology. > Jun 2014 Summarize results of specifying, implementing, and testing > LISP and forward to IESG and/or IRTF. > Jun 2014 Analyze and document the implications of LISP deployments in > Internet topologies and forward to IESG for publication. > Dec 2014 Re-charter or close > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
