Hi Marshal, Previous charter discussions suggested that it wasn't necessary to include an outside webpage for 'further' reading, I tend to agree as outside pages (thus not tools based) tend to date really quickly if not actively maintained.
That said, if there is a page that does cover _all_ [1] that auxiliary material in one place I'd be happy to look, review, and reconsider by reopening the WG discussion. [1] implementations, research papers, experimental work, additional works etc. Terry On 3/12/11 2:38 AM, "Marshall Eubanks" <marshall.euba...@gmail.com> wrote: > 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 > <terry.mander...@icann.org> 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 >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
