The IESG had a call today and approved the charter as it is below. The 
official announcement comes out early next week.

I realize that there were a few people who were unhappy with the charter 
but I think in the end we have rough consensus to move forward. I looked 
at the discussion, we got a few alternative proposals but after some 
thinking I did not see a reason to deviate from the charter that the 
chairs had came up with.

There were small editorial changes to the charter: garbled text about 
the IAB workshop, removing the dangling reference the RLOC term later in 
the text, deletion of the word "other" from the sentence that describes 
parallel work in the IRTF and IETF [I didn't want to create an 
impression that only the other approaches are at an early stage], and 
changed IPV4 to IPv4 [same for IPv6].

So its time to get to the technical work, full steam ahead! Please 
remember that the success of this WG depends primarily on what you learn 
from discussions between different people in the group and from testing 
Lisp, not so much on pushing out RFCs at the earliest possible date. 
Take time to go through everything so that we actually understand the 
technology and its implications.

Jari

Locator/ID Separation Protocol (lisp)
--------------------------------------------------
Last Modified: 2009-04-23

Current status: Working Group

Chair(s):
Sam Hartman <hartmans-ietf@mit.edu>
Darrel Lewis <darlewis@cisco.com>

Internet Area Director(s):
Jari Arkko <jari.arkko@piuha.net>
Ralph Droms <rdroms@cisco.com>

Internet Area Advisor:
Jari Arkko <jari.arkko@piuha.net>

Mailing Lists:
General Discussion: https://www.ietf.org/mailman/listinfo/lisp

Description of Working Group:

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 the IRTF and 
IETF. At this time, these proposals are at an early stage. All proposals 
(including LISP) have potentially harmful side-effects to Internet 
traffic carried by the involved routers, have parts where deployment 
incentives may be lacking, and are NOT RECOMMENDED for deployment beyond 
experimental situations at this stage. Many of the proposals have 
components (such as the identifier to locator mapping system) where it 
is not yet known what kind of design alternative is the best one among 
many.

However, despite these issues it would be valuable to write concrete 
protocol specifications and develop implementations that can be used to 
understand the characteristics of these designs. The LISP WG is 
chartered to work on the LISP base protocol 
(draft-farinacci-lisp-12.txt), the LISP+ALT mapping system 
(draft-fuller-lisp-alt-05.txt), LISP Interworking 
(draft-lewis-lisp-interworking-02.txt), LISP Map Server 
(draft-fuller-lisp-ms-00.txt), and LISP multicast 
(draft-farinacci-lisp-multicast-01.txt) for these purposes, with the 
given drafts as a starting point. 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 the ALT and/or other 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 
(draft-meyer-loc-id-implications) as well as the manageability and 
operability of LISP.

Goals and Milestones:

Mar 2010 Submit base LISP specification to the IESG as Experimental

Mar 2010 Submit base ALT specification to the IESG as Experimental

Mar 2010 Submit the LISP Interworking specification to the IESG as 
Experimental

June 2010 Submit the LISP Map Server specification to the IESG as 
Experimental

June 2010 Submit Recommendations for Securing the LISP Mapping System to 
the IESG as Experimental

Jul 2010 Submit LISP for Multicast Environments to the IESG as Experimental

Dec 2010 Submit a preliminary analysis as Informational

Dec 2010 Re-charter or close.