Locator/ID Separation Protocol
charter-ietf-lisp-03-00

WG review announcement

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: lisp@ietf.org 
Subject: WG Review: Locator/ID Separation Protocol (lisp)

The Locator/ID Separation Protocol (lisp) WG in the Routing Area of the
IETF is undergoing rechartering. The IESG has not made any determination
yet. The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG
mailing list (iesg@ietf.org by 2016-02-02.

Locator/ID Separation Protocol (lisp)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Joel Halpern <jmh@joelhalpern.com>
  Luigi Iannone <ggx@gigix.net>

Secretaries:
  Damien Saucez <damien.saucez@gmail.com>
  Wassim Haddad <Wassim.Haddad@ericsson.com>

Area Directors:
  TBD

Assigned Area Director:
  Deborah Brungard <db3546@att.com>

Mailing list:
  Address: lisp@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/lisp
  Archive: https://mailarchive.ietf.org/arch/browse/lisp/

Charter: https://datatracker.ietf.org/doc/charter-ietf-lisp/


The LISP WG has completed the first set of Experimental RFCs describing
the Locator/ID Separation Protocol (LISP). LISP supports a routing
architecture which decouples the routing locators and identifiers, thus
allowing for efficient aggregation of the routing locator space and
providing persistent identifiers in the identifier space. 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 scope of the LISP technology is recognized to
range from unicast and multicast overlays at Layer 2 as well as at Layer
3,
including NAT traversal, VPNs, and supporting mobility as a general
feature,
independently of whether it is a mobile user or a migrating Virtual
Machine (VM), hence being applicable in both Data Centers and public
Internet environments.

The LISP WG is chartered to continue work on the LISP base protocol with
the
main objective to develop a standard solution based on the completed
Experimental RFCs and the experience gained from early deployments.

The work will include reviewing the existing set of Experimental RFCs and
doing the necessary enhancements to support a base set of standards
track RFCs. The group will review the current set of Working Group
documents to identify potential standards-track documents and do
the necessary enhancements to support standards-track. It is
recognized that some of the work will continue on the experimental
track, though the group is encouraged to move the documents to standards
track in support of network use, whereas the work previously was scoped
to
experimental documents.

Besides this main focus, the LISP WG may work on the following items:

  - Multi-protocol support: Specifying the required extensions to
support multi-protocol encapsulation (e.g., L2 or NSH (Network
Service Headers). Rather than developing new encapsulations the
work will aim at using existing well-established encapsulations or
emerging from other Working Groups such as NVO3 and SFC.
  
  - Alternative Mapping System Design: By extending LISP with new
protocols to support, it is also necessary to develop the required
mapping function and control plane extensions to operate LISP
map-assisted networks (which may include Hierarchical Pull,
Publish/Subscribe, or Push models, independent mapping systems
interconnection, security extensions, or alternative transports of the
LISP control protocol).
  
  - Mobility: Some LISP deployment scenarios include mobile nodes
(in mobile environments) or Virtual Machines (VMs in data centers),
hence support needs to be provided in order to achieve seamless
connectivity.
  
  - Multicast: Support for overlay multicast by means of replication
as well as interfacing with existing underlay multicast support.
 
  - Data-Plane Encryption: In some scenarios, it may be desirable to
encrypt LISP encapsulated traffic. In this case, the data-plane
encryption mechanism itself and support for control-plane
security information exchange needs to be specified.
  
  - NAT-Traversal: Support for a NAT-traversal solution in deployments
where a LISP xTR is separated from correspondent xTR(s) by a NAT
(e.g., LISP mobile node).
  
  - Management models: Support for managing the LISP protocol and
deployments that include data models, as well as allowing for
programmable management interfaces. These management methods
should be considered for both the data-plane, control plane,
and mapping system components.
 

Milestones:


WG action announcement

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: lisp-chairs@ietf.org,
    lisp@ietf.org,
    "The IESG" <iesg@ietf.org> 
Subject: WG Action: Rechartered Locator/ID Separation Protocol (lisp)

The Locator/ID Separation Protocol (lisp) WG in the Routing Area of the
IETF has been rechartered. For additional information, please contact the
Area Directors or the WG Chairs.

Locator/ID Separation Protocol (lisp)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Joel Halpern <jmh@joelhalpern.com>
  Luigi Iannone <ggx@gigix.net>

Secretaries:
  Damien Saucez <damien.saucez@gmail.com>
  Wassim Haddad <Wassim.Haddad@ericsson.com>

Area Directors:
  TBD

Assigned Area Director:
  Deborah Brungard <db3546@att.com>

Mailing list:
  Address: lisp@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/lisp
  Archive: https://mailarchive.ietf.org/arch/browse/lisp/

Charter: https://datatracker.ietf.org/doc/charter-ietf-lisp/


The LISP WG has completed the first set of Experimental RFCs describing
the Locator/ID Separation Protocol (LISP). LISP supports a routing
architecture which decouples the routing locators and identifiers, thus
allowing for efficient aggregation of the routing locator space and
providing persistent identifiers in the identifier space. 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 scope of the LISP technology is recognized to
range from unicast and multicast overlays at Layer 2 as well as at Layer
3,
including NAT traversal, VPNs, and supporting mobility as a general
feature,
independently of whether it is a mobile user or a migrating Virtual
Machine (VM), hence being applicable in both Data Centers and public
Internet environments.

The LISP WG is chartered to continue work on the LISP base protocol with
the
main objective to develop a standard solution based on the completed
Experimental RFCs and the experience gained from early deployments.

The work will include reviewing the existing set of Experimental RFCs and
doing the necessary enhancements to support a base set of standards
track RFCs. The group will review the current set of Working Group
documents to identify potential standards-track documents and do
the necessary enhancements to support standards-track. It is
recognized that some of the work will continue on the experimental
track, though the group is encouraged to move the documents to standards
track in support of network use, whereas the work previously was scoped
to
experimental documents.

Besides this main focus, the LISP WG may work on the following items:

  - Multi-protocol support: Specifying the required extensions to
support multi-protocol encapsulation (e.g., L2 or NSH (Network
Service Headers). Rather than developing new encapsulations the
work will aim at using existing well-established encapsulations or
emerging from other Working Groups such as NVO3 and SFC.
  
  - Alternative Mapping System Design: By extending LISP with new
protocols to support, it is also necessary to develop the required
mapping function and control plane extensions to operate LISP
map-assisted networks (which may include Hierarchical Pull,
Publish/Subscribe, or Push models, independent mapping systems
interconnection, security extensions, or alternative transports of the
LISP control protocol).
  
  - Mobility: Some LISP deployment scenarios include mobile nodes
(in mobile environments) or Virtual Machines (VMs in data centers),
hence support needs to be provided in order to achieve seamless
connectivity.
  
  - Multicast: Support for overlay multicast by means of replication
as well as interfacing with existing underlay multicast support.
 
  - Data-Plane Encryption: In some scenarios, it may be desirable to
encrypt LISP encapsulated traffic. In this case, the data-plane
encryption mechanism itself and support for control-plane
security information exchange needs to be specified.
  
  - NAT-Traversal: Support for a NAT-traversal solution in deployments
where a LISP xTR is separated from correspondent xTR(s) by a NAT
(e.g., LISP mobile node).
  
  - Management models: Support for managing the LISP protocol and
deployments that include data models, as well as allowing for
programmable management interfaces. These management methods
should be considered for both the data-plane, control plane,
and mapping system components.
 

Milestones:


Ballot announcement

As discussed, the LISP WG has completed their initial set of RFCs and they are requesting to recharter with the main aim to develop a standards track solution. In addition, they will continue to work on previous items and some new items.