Re: [lisp] Proposed LISP WG Charter

Luigi Iannone <ggx@gigix.net> Fri, 22 January 2016 12:21 UTC

Return-Path: <ggx@gigix.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01231A1B0D for <lisp@ietfa.amsl.com>; Fri, 22 Jan 2016 04:21:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgZgsptoagIQ for <lisp@ietfa.amsl.com>; Fri, 22 Jan 2016 04:21:55 -0800 (PST)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774CE1A1B0C for <lisp@ietf.org>; Fri, 22 Jan 2016 04:21:54 -0800 (PST)
Received: by mail-wm0-x233.google.com with SMTP id r129so211027651wmr.0 for <lisp@ietf.org>; Fri, 22 Jan 2016 04:21:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xkFxATecVbeFwm62d2VNwVQ8JBBSMSSRNcqEs1Qjwos=; b=gBdBeBmQ7HE+1PGhChSpkLMOosB5qNCOQqRC8mZ3GqktNjx4qfa9CHsIdVoA7qhRmf nZqMdOmc2Jilm05taKE7TRSPDPLWPUxzSV1piTRptgf1BjSoS0IAQFk4HRs++fprNP5F o7RmgFb1Gf1rH0XtpAKKs9hJSplBul30cavr0qXgvp7uJjJuRowKGjkHYf13aZ9DL9Id zBq6HMWJsXYpyz8x/00TKqLOswQlhK31irtLm9qlCyIpiGfZTZFsLiRmfi0h30cROZxS I8dhkcufKO2aKoqLuLvV1WBCtZoHKywCoQxbTTfQ5pTNxJbOKABrf42OVIOYC1XCJsYQ ikGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=xkFxATecVbeFwm62d2VNwVQ8JBBSMSSRNcqEs1Qjwos=; b=ML8bmZVwG0djgcb5PJAgbnspj+iJmB6PrwGRZtayW1oVkoT/gQsukxp0EU75k3l38w EOD0ESixDTzA8pj/3aLPRRCVxjrlFWatLUWdtUWB015YSUIQm9MymklGBRawueCmIUuU xFuv26syGKdv19hBaJwtTvI+0UH+c41qhZ57HOjbLb7B3i9OXD0uvNT435jXo47GGhQF predK6B7BbMVHJ3vz3yk9IjVBSZmU2myjcyjpAo6U+PeyRv2DnTeA+aBTSdfx9RFp7hR YcsE+0kAl1FD/mzKEw9EWyOu+N1FvISTrbU/4rDBlfGrX+H+gJYQnMiDYAp0ZX3UdVYn FSrQ==
X-Gm-Message-State: AG10YOS5zEdoXWNPo3XsBuLwI2/G4kKm/b+BpoLKWgq7N3zhRSK29e8plfXNC3914kZKMg==
X-Received: by 10.28.217.83 with SMTP id q80mr3138321wmg.15.1453465313082; Fri, 22 Jan 2016 04:21:53 -0800 (PST)
Received: from ?IPv6:2001:660:330f:a4:adc3:e949:4c2:4b5a? ([2001:660:330f:a4:adc3:e949:4c2:4b5a]) by smtp.gmail.com with ESMTPSA id p9sm5686192wjy.41.2016.01.22.04.21.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 04:21:51 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Luigi Iannone <ggx@gigix.net>
In-Reply-To: <C7AB49B7-05FE-4388-A7F7-BCD8F2E4830F@gigix.net>
Date: Fri, 22 Jan 2016 13:21:53 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A03A613-0E8C-48F6-97D5-E3D919041068@gigix.net>
References: <EA0997EC-B945-41A3-A11E-98A5DB1C30E8@gigix.net> <F64C10EAA68C8044B33656FA214632C8527DC7F2@MISOUT7MSGUSRDE.ITServices.sbc.com> <C7AB49B7-05FE-4388-A7F7-BCD8F2E4830F@gigix.net>
To: "BRUNGARD, DEBORAH A" <db3546@att.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/fXwgoQc02psiap02N7SjhUqFk-c>
Cc: Joel Halpern Direct <jmh.direct@joelhalpern.com>, LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] Proposed LISP WG Charter
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2016 12:21:57 -0000

Hi Deborah,

Hereafter you can find an updated charter with additional wording on the items you suggested.

Let us know what you think.

ciao

Luigi


%%%%%%%% LISP WG PROPOSED CHARTER %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



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: Some LISP deployment scenario 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 material exchange needs to be specified.

 

·       NAT-Traversal: Support for NAT-traversal solution in deployments where a LISP xTR is separated from correspondent xTR(s) 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 managament methods should be considered for both the data-plane, control-plane, and mapping system components.

 

 

 



> On 20 Jan 2016, at 12:01, Luigi Iannone <ggx@gigix.net> wrote:
> 
> This can be surely be done.
> 
> Will update the proposed charter before the end of the week.
> 
> ciao
> 
> L.
> 
> 
>> On 19 Jan 2016, at 23:58, BRUNGARD, DEBORAH A <db3546@att.com> wrote:
>> 
>> Hi Luigi,
>> 
>> Looks good - can you add a few words to scope better the three bullet items: mobility, data-plane encryption, NAT-Traversal?
>> 
>> Thanks,
>> Deborah
>> 
>> 
>> -----Original Message-----
>> From: Luigi Iannone [mailto:ggx@gigix.net] 
>> Sent: Friday, January 15, 2016 4:15 AM
>> To: BRUNGARD, DEBORAH A <db3546@att.com>; Joel Halpern Direct <jmh.direct@joelhalpern.com>
>> Cc: LISP mailing list list <lisp@ietf.org>
>> Subject: Proposed LISP WG Charter
>> 
>> Hi Deborah,
>> 
>> The LISP WG had a final round of discussion (on the mailing list) 
>> earlier this month on the new proposed charter.
>> 
>> Hereafter you can find the outcome.
>> This version includes all items the WG is ready to work on.
>> 
>> thanks
>> 
>> ciao
>> 
>> Luigi
>> 
>> 
>> %%%%%%%% LISP WG PROPOSED CHARTER %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>> 
>> 
>> 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, independent 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.
>> 
>