Re: [lisp] Update Proposed CHarter

"Vina Ermagan (vermagan)" <> Wed, 06 January 2016 20:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E32951A03ED for <>; Wed, 6 Jan 2016 12:46:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 488JEczoW83k for <>; Wed, 6 Jan 2016 12:46:15 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 346EE1A03A9 for <>; Wed, 6 Jan 2016 12:46:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3582; q=dns/txt; s=iport; t=1452113175; x=1453322775; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dNEEe222H4NDr1ja0NDeXm8+3n3AB26AUe/p67GGfGk=; b=TzgPuIY4pWRDKpQvlNpNvgvlH//4BUbZ8dB4kbjY1Uit0Q9jQcANbyu7 5eCsSoXmSAj+glFr7loT0pkJSnQbaHexZNcOZUzYIy3p/hIblnw9Gu7UR gWHpwvsK8JjAmCRqtFlijMAURSxHzIThjumT5JWHcXQBTJVYF0GRiCE2b A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAgBffI1W/5FdJa1UCoM6Um0GiFOzX?= =?us-ascii?q?AENgWQYCoVtAoEmOBQBAQEBAQEBgQqENQEBBAEBAWkCCxACAQgOBBIiJwsXDgI?= =?us-ascii?q?EAQ0FG4gUDsF7AQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVoN7gQSELCmEZwWNc?= =?us-ascii?q?4kXAY1UgVyEQ4hbhV6IaAEgAQFChApyhFmBCAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.20,530,1444694400"; d="scan'208";a="64634236"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2016 20:46:14 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u06KkEIb009958 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jan 2016 20:46:14 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Jan 2016 14:46:13 -0600
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Wed, 6 Jan 2016 14:46:13 -0600
From: "Vina Ermagan (vermagan)" <>
To: Luigi Iannone <>, LISP mailing list list <>
Thread-Topic: [lisp] Update Proposed CHarter
Thread-Index: AQHRRu21HHJELY4k+UCUQcVryKwMOJ7u96aA///fhIA=
Date: Wed, 6 Jan 2016 20:46:13 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: Joel Halpern Direct <>
Subject: Re: [lisp] Update Proposed CHarter
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Jan 2016 20:46:17 -0000

Thanks Luigi, this version looks great.


On 1/6/16 6:42 AM, "Luigi Iannone" <> wrote:

>Hi All,
>Hereafter a new version of the charter with the comments received so far.
>Please send more feedback. Would be good if we can send the charter to
>our AD by next week.
>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 techology 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 wheter it is a mobile user or a migrating VM,
>hence being applicable in both Data Centers and public Internet
>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.
>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. 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
>Beside this main focus, the LISP WG 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 Grops such as  NVO3 and SFC.
>·       Alternative Mapping System Design. By extenting LISP with  new
>protocols support it is also 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, independednt mapping systems interconnection, security
>extensions, or alternative transports of the LISP control protocol).
>·       Mobility
>·       Multicast: Support for overlay multicast by means of replication
>as well as interfacing with existing underlay multicast support.
>·       Data-Plane Encryption
>·       NAT-Traversal
>·       Models for managing the LISP protocol and deployments that
>include data models, as well as allowing for programmable management
>interfaces. These managament methods should be considered for both the
>data-plane, control-plane, and mapping system components.
>lisp mailing list