Locator/ID Separation Protocol (lisp)
-------------------------------------

 Charter

 Current Status: Active

 Chairs:
     Joel M. Halpern <[email protected]>
     Luigi Iannone <[email protected]>

 Routing Area Directors:
     Alia Atlas <[email protected]>
     Deborah Brungard <[email protected]>
     Alvaro Retana <[email protected]>

 Routing Area Advisor:
     Deborah Brungard <[email protected]>

 Secretaries:
     Damien Saucez <[email protected]>
     Wassim Haddad <[email protected]>

 Mailing Lists:
     General Discussion: [email protected]
     To Subscribe:       https://www.ietf.org/mailman/listinfo/lisp
     Archive:            http://www.ietf.org/mail-archive/web/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. 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.

    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 has completed the first set of Experimental RFCs
    describing the Locator/ID Separation Protocol. LISP requires no
    changes to end-systems or to routers that do not directly participate
    in the LISP deployment. LISP aims for an incrementally deployable
    protocol.

    The LISP WG is chartered to continue work on the LISP base protocol, completing
    the ongoing work, and any items which directly impact LISP protocol
    structures and which are related to using LISP for improving Internet routing
    scalability. Specifically, the group will work on:

    - Architecture description: This document will describe the
    architecture of the entire LISP system, making it easier to read the
    rest of the LISP specifications and providing a basis for discussion
    about the details of the LISP protocols. The document will include
    a description of the cache management and ETR synchronization
    essential characteristics needed to ensure the correct operation
    of the protocol.

    - Deployment models: This document will describe what kind of
    deployments can be expected for LISP, and give operational advice on
    how they can be set up.

    - A description of the impacts of LISP: This document will describe
    the problems that LISP is intended to address and the impacts that
    employing LISP has. While the work on LISP was initiated by Internet
    routing scaling concerns, there has also been an interest on
    improved solutions to a number of different problems, such as
    traffic engineering. This document should describe problem areas
    (such as scaling or traffic engineer) where LISP is expected to have
    a positive effect, as well as any tradeoffs that are caused by
    LISP's design.

    - LISP security threats and solutions: This document will describe the
    security analysis of the LISP system, what issues it needs to
    protect against, and a solution that helps defend against those
    issues. The replay attack problem discussed on the mailing list
    should be included in this work.

    - Allocation of Endpoint IDentifier (EID) space: This document
    requests address space to be used for the LISP experiment as
    identifier space

    - Alternate mapping system designs: Develop alternative mapping
    designs to be tested.

    - Data models for management of LISP.

    The first three items (architecture, deployment models, impacts) need
    to be completed first before other items can be submitted as RFCs. The
    three first documents also need to complement each other, by
    describing how the architecture supports a solution for a particular
    problem area and how the solution can be deployed to help with that
    problem.

    In addition, if work chartered in some other IETF WG requires changes
    in the LISP base protocol or any items which directly impact LISP
    protocol structures, then the LISP WG is chartered to work on such
    changes.

    It is expected that the results of specifying, implementing, and testing
    LISP will be fed to the general efforts at the IETF and IRTF to
    understand which type of a solution is optimal. The LISP WG is not
    chartered to develop a standard solution for solving the routing
    scalability problem at this time. The specifications developed by the WG
    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.



Goals and Milestones:
  Sep 2012 - Submit a LISP impact discussion document to the IESG for publication as an Experimental RFC
  Sep 2012 - Submit an architecture description to the IESG for publication as an Experimental RFC
  Oct 2012 - Submit an EID allocation document to the IESG for publication as an Experimental RFC
  Oct 2012 - Submit a LISP threats analysis document to the IESG for publication as an Experimental RFC
  Jan 2013 - Submit an lternate mapping system designs to the IESG for publication as an Experimental RFC
  Mar 2013 - Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF.
  Done     - Submit a deployment model document to the IESG for publication as an Experimental RFC
  Done     - Submit a data model (e.g., a MIB) document to the IESG for publication as an Experimental RFC