[lisp] gpe-vpn draft

2016-04-07 Thread Joel M. Halpern

A nitpicking request...
When you refresh this, could you call it draft-maino-lisp-gpe-vpn so the 
tools pcik it up automatically?


Thank you,
Joel

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


[lisp] Fwd: New Version Notification for draft-portoles-lisp-eid-mobility-00.txt

2016-04-07 Thread Victor Moreno (vimoreno)
Dear Workgroup,

Please refer to this recent draft submission for context on the Agenda slot 
this afternoon referring to the unified control plane work.

Kind Regards,

Victor

Begin forwarded message:

From: mailto:internet-dra...@ietf.org>>
Subject: New Version Notification for draft-portoles-lisp-eid-mobility-00.txt
Date: April 7, 2016 at 12:08:32 PM GMT-3
To: Dino Farinacci mailto:farina...@gmail.com>>, Vrushali 
Ashtaputre mailto:vrush...@cisco.com>>, Marc 
Portoles-Comeras mailto:mport...@cisco.com>>, "Victor 
Moreno" mailto:vimor...@cisco.com>>, Marc Portoles Comeras 
mailto:mport...@cisco.com>>, Fabio Maino 
mailto:fma...@cisco.com>>


A new version of I-D, draft-portoles-lisp-eid-mobility-00.txt
has been successfully submitted by Fabio Maino and posted to the
IETF repository.

Name: draft-portoles-lisp-eid-mobility
Revision: 00
Title: LISP L2/L3 EID Mobility Using a Unified Control Plane
Document date: 2016-04-07
Group: Individual Submission
Pages: 20
URL:
https://www.ietf.org/internet-drafts/draft-portoles-lisp-eid-mobility-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-portoles-lisp-eid-mobility/
Htmlized:   https://tools.ietf.org/html/draft-portoles-lisp-eid-mobility-00


Abstract:
  The LISP control plane offers the flexibility to support multiple
  overlay flavors simultaneously.  This document specifies how LISP can
  be used to provide control-plane support to deploy a unified L2 and
  L3 overlay solution, as well as analyzing possible deployment options
  and models.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

The IETF Secretariat


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


[lisp] WG Review: Locator/ID Separation Protocol (lisp)

2016-04-07 Thread The IESG
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 (i...@ietf.org) by 2016-04-18.

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

Chairs:
  Joel Halpern 
  Luigi Iannone 

Secretaries:
  Damien Saucez 
  Wassim Haddad 

Assigned Area Director:
  Deborah Brungard 

Routing Area Directors:
  Alia Atlas 
  Alvaro Retana 
  Deborah Brungard 
 
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 potentially applicable to
have a large span, including unicast and multicast overlays at Layer 2 as
well as at Layer 3, encompassing 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, the LISP technology is
applicable in both Data Centers and public Internet environments.

The LISP WG is chartered to continue work on the LISP base protocol and
produce standard-track documents (unless the content of the document
itself is of a different type, e.g., informational or experimental). In
order to
produce a coherent set of documents, the first (and high priority) work
item
of the LISP Working Group is to develop a standard-track solution based
on the
completed Experimental RFCs and the experience gained from early
deployments. This 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.

In parallel with the previous main work item, the LISP WG will work on
the items listed below:

  - 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
multi-protocols support, it becomes necessary to develop the required
mapping function and control plane extensions to operate LISP
map-assisted networks (which might 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. This work item may benefit from experience of other
Working Groups like DMM (Distributed Mobility Management) or NVO3
(for VM migration).
  
  - Multicast: Support for overlay multicast by means of replication
as well as interfacing with existing underlay multicast support. This
may need discussion with other Working Groups related to multicast
solutions (e.g. PIM).
 
  - 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
material exchange needs to be specified. Any solution proposed in this
work item has to be reviewed by security experts. 
  
  - NAT-Traversal: Support for NAT-traversal solution in deployments
where LISP tunnel routers are separated from correspondent tunnel
routers by a NAT (e.g., LISP mobile node).
  
  - Models 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 of standards-track
documents.

Documents of these work items will as well target standard-track unless
the main content of the document itself clearly demands for a different
type (e.g., informational or experimental