Terry, > WG hat on. > > This follow-up is initiated due to a recent observation gleaned from a > presentation request for the Taipei meeting. > > While this draft charter does not preclude taking on work items specifically > related to LISP VPN or LISP mobility, I think it's useful to tease out the > questions and put them to the WG for discussion. > > Should LISP mobility be specifically included in the work plan? > > Should LISP VPN modalities be specifically included in the work plan?
If LISP VPN modality is an L2VPN, then such work should be pursued in L2VPN WG. If LISP VPN modality is an L3VPN, then such work should be pursued in L3VPN WG. Thus both of of the above LISP VPN modalities should be outside the scope of the LISP WG. Yakov. > > Cheers > Terry > > On 20/10/11 9:23 AM, "Terry Manderson" <terry.mander...@icann.org> wrote: > > > Hi All, > > > > Joel and I bounced the following charter around and have also passed it in > > front of AD's eyes. > > > > You obviously have time to chew on this for a while before Taipei. > > > > 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. 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 draft-ietf-lisp-deployment to the IESG. > > Jun 2012 Forward a security proposal document (draft-ietf-lisp-threats) > > to the IESG. > > > > Dec 2013 Forward to the IESG an operational set of documents which shoul d > > include cache management and ETR synchronization > > techniques inclusive of a cache management specification. > > > > Jun 2014 Forward to the IESG an evaluation of the security threat to > > cache management and ETR synchronization. > > Jun 2014 Evaluate the applicability and coverage for LISP from a > > reuse of SIDR technology. > > > > Dec 2014 Re-charter or close > > > > > > Cheers > > Terry > > > > _______________________________________________ > > 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 _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
