Re: [lisp] Update Proposed CHarter

Luigi Iannone <> Mon, 11 January 2016 14:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1F23C1A00B0 for <>; Mon, 11 Jan 2016 06:00:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ou5obgwBmVpQ for <>; Mon, 11 Jan 2016 06:00:41 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 377421A00CF for <>; Mon, 11 Jan 2016 06:00:41 -0800 (PST)
Received: by with SMTP id f206so269930182wmf.0 for <>; Mon, 11 Jan 2016 06:00:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e2aZCk4utBnCqLMal+u0i3oWw6sGafjrS0O1WLs/iR0=; b=svSvT0YiE3/PudFcPobvBzQTHgyB0xklE4633gbYtEwUKFFvHTjxz5zfAy0ecyTqjW q+hSxmm5ut8FXGwUpVuMR/EuvObSTYQshEqUPfSnfMcqEWpW0mv0XuHDyTKt9kNnlt00 o0htmmJL6apVqEAOlI10Ew3eRT0zL8o6UUvd6xHXD530nrCbPWZixCqSGonhT+iDmRA2 qRmhbKxDbZbOn7T9iuS8UpamcBJbY8C1HcTNF3jKL/bGY64ugI2RKVzRwQ4Vp93kXFGr qi1u8IN93RJ6LvwAsMUlj6c19GTQrw0ANzTRhRLi0NzouDUdr74AGwewGeuCaTeGh+e1 3/yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=e2aZCk4utBnCqLMal+u0i3oWw6sGafjrS0O1WLs/iR0=; b=DM8IdnSrXrMGLtiNO0x3ww6brGPoEmC4SpbB/txh2qvKKaiJHCwvT8j8YHMLd6cP3l HYcm3EVsLn78GsAn95LhYAnDQGxKnwqwz2ksngn6IcC9sXo6mj11x8ZKhOxwZ7D2xW53 wdr/mRkN8Lm6++s8aKXvuUnqogp6JSzRjqWeyZLQj0/v6aLK8WfOJvGDakSm1sgXuWpS UsVY856u4qXy8jn87UoHA5Gb7YvYI4M2ABiuRGKtNJNgsm2BzU0UnkZxaHCk+w6RU69I Ol7Z0ohSZWx4aLbqSOpqawoUROhWgHU/kEsA1lmJVxuCyQbBZwitgwxcQe7vWCNL95el ASdg==
X-Gm-Message-State: ALoCoQnlU0e3jRE6+5A1hQgHQLVrkZnB5uqSCNmPedzhtXAgvc88aLiP9UhXHeAkEMYEtAZtdpDlVVbs7+R1SMo8Nj7XlDBWiQ==
X-Received: by with SMTP id f189mr12988401wme.25.1452520839711; Mon, 11 Jan 2016 06:00:39 -0800 (PST)
Received: from ( []) by with ESMTPSA id f205sm13004794wme.4.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Jan 2016 06:00:38 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Luigi Iannone <>
In-Reply-To: <>
Date: Mon, 11 Jan 2016 15:00:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: "Darrel Lewis (darlewis)" <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Cc: Joel Halpern Direct <>, LISP mailing list list <>
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: Mon, 11 Jan 2016 14:00:43 -0000

Hi Darrel,

I am not sure I follow your comment. 
Both Pub/Sub and reliable transport are mentioned in the proposed draft.

Can you elaborate a bit what  in your opinion is missing?



> On 09 Jan 2016, at 23:04, Darrel Lewis (darlewis) <> wrote:
> Luigi,
> Where would enhancements of the protocol - like Reliable Transport - fit into the below text?  I’d like to make sure that things like this and a pub/sub distribution model are explicitly mentioned, because they are actively being developed by multiple implementers - maybe ‘alternative Mapping System Design’ is too narrow a focus?
> -Darrel
> On Jan 6, 2016, at 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.
>> ciao
>> L.
>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>> 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 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.
>> 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 documents.
>> 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