Re: [lisp] Draft of new Proposed Charter
"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 14 October 2015 23:04 UTC
Return-Path: <jmh@joelhalpern.com>
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 B07831A01F9 for <lisp@ietfa.amsl.com>; Wed, 14 Oct 2015 16:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 DQWSQ8PakF4U for <lisp@ietfa.amsl.com>; Wed, 14 Oct 2015 16:04:16 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955BC1A01D8 for <lisp@ietf.org>; Wed, 14 Oct 2015 16:04:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 811F6240771; Wed, 14 Oct 2015 16:04:16 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D63FA24073E; Wed, 14 Oct 2015 16:04:15 -0700 (PDT)
To: Albert Cabellos <albert.cabellos@gmail.com>, Luigi Iannone <ggx@gigix.net>
References: <B25C7BF8-93D4-464E-8A3E-88720612E0AD@telecom-paristech.fr> <561D7D55.3090305@cisco.com> <CAGE_Qex6iVji+9=Fw79DeNQ+YAUpy_EcU-Yhr4NruOYADKzNnw@mail.gmail.com> <DE654947-A08B-47DD-A3FA-7DE611C42BA4@gigix.net> <CAGE_Qewmo6d4n+f0MLVMH7kje_H+BVRj33h7H876Fs3JLR-LLQ@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <561EDF6E.60805@joelhalpern.com>
Date: Wed, 14 Oct 2015 19:04:14 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAGE_Qewmo6d4n+f0MLVMH7kje_H+BVRj33h7H876Fs3JLR-LLQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/CM1J_2-8Gngd7hBOsYF7dDI8_5o>
Cc: "lisp@ietf.org" <lisp@ietf.org>
Subject: Re: [lisp] Draft of new Proposed 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: Wed, 14 Oct 2015 23:04:18 -0000
I am really unclear as to what the problem being addressed by creating a programmatic language for LCAFs is. Heck, I am confused by what the JSON LCAFs are solving too. Beyond that, I do not even know what it means to support such LCAF through a mapping system. It sounds a lot like research, rather than engineering. But I that may be just because I have completely missed the point. Yours, Joel On 10/14/15 6:10 PM, Albert Cabellos wrote: > Hi Luigi > > Please see my comments inline: > > On Wed, Oct 14, 2015 at 1:31 AM, Luigi Iannone <ggx@gigix.net> wrote: > > [snip] > >> Having design guidelines does not forcedly mean having a programmatic language approach. Right? >> >> In your opinion could well defined guidelines (not language) be added to the current LCAF document? > > I am unsure if we can do this without ending up reproducing some sort > of language, we´ll start by defining scalar data-types, then complex > data-types (combinations of scalars), then data-structures, then > encoding mechanisms for each scalar and each data-structure and so on. > > This could be as simple as defining an encoding mechanisms for YANG > (XMLBIN with some sort of compression). I am not stating that we > should go this precise way, what I am stating is that LCAF is rigid > and, if a new use-case is not defined as an LCAF, it can´t be deployed > in a standard way. A language could solve this issue and make the LISP > control plane truly flexible. > >> >>> to define new ones. A flexible language with a clear >>> syntax would ease deployment of new use-cases both at the data and >>> control plane. >> >> How much relevant and with what priority is this for the WG? ( _NOTE_ this question is for the whole WG not just for Albert…) >> > > me too :) > > Albert > >>> Maybe this could be done as experimental (not >>> standard). >> >> _if_ the WG decides to take on this work it would very reasonable to go for experimental. >> >> ciao >> >> L. >> >> >>> >>> Albert >>> >>> >>> On Tue, Oct 13, 2015 at 2:53 PM, Fabio Maino <fmaino@cisco.com> wrote: >>>> >>>> Joel, Luigi, >>>> thanks for taking a stab at this one. >>>> >>>> I think it covers the relevant aspects that I would like to see the WG to focus on. >>>> >>>> As discussed in the use case thread, I would suggest that the draft should mention a very small set of use cases that we can use to drive the design decisions. I think that we can possibly cover all of the protocol aspects you describe if we take the following two use cases: >>>> 1) LISP-based programmable L2/L3 VPNs with extensions to support the following services: >>>> - encryption >>>> - programmatic northbound access to the mapping and to xTR configuration >>>> - SFC/NFV >>>> - VPN termination on mobile nodes >>>> 2) LISP-based programmable L2/L3 VPNs for DC applications >>>> >>>> I think these two will give a good scope to the WG work and, without resorting to more exotic use cases, reinforce the focus on the use of LISP as an overlay technology. >>>> >>>> Thanks, >>>> Fabio >>>> >>>> >>>> >>>> >>>> On 10/13/15 1:30 PM, Luigi Iannone wrote: >>>>> >>>>> Folks, >>>>> >>>>> in the past weeks (and months) there was a fruitful discussion that took place on the mailing list (and also in Prague) concerning >>>>> the new charter to be adopted by our WG. Thanks for this effort. >>>>> >>>>> Beside this discussion we had proposals from WG members as well as discussion with our AD about what is practical and reasonable. >>>>> Hereafter you can find the result: a draft of the new proposed charter. >>>>> >>>>> This does not mean that discussion is over, rather that we reached a first consistent milestone for further discussion. >>>>> Discussion ideally culminating in our meeting in Japan. >>>>> >>>>> So please have look and send your thoughts and feedback to the mailing list. >>>>> >>>>> Joel and Luigi >>>>> >>>>> %—————————————————————————————————————————————————% >>>>> 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 programmable overlays, >>>>> at Layer 2 as well as at Layer 3, including NAT traversal, and >>>>> supporting mobility as a general feature, independently of whether >>>>> 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 research studies. >>>>> >>>>> Beside this main focus, the LISP WG may work on the following items: >>>>> >>>>> • NAT-Traversal >>>>> • Mobility >>>>> • Data-Plane Encryption >>>>> • Multicast: Support for overlay multicast by means of replication >>>>> as well as interfacing with existing underlay multicast support. >>>>> • YANG Data models for management of LISP. >>>>> • 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: When extending LISP to support >>>>> new protocols,it may be also necessary to develop the related mapping >>>>> function extensions to operate LISP map-assisted networks (which >>>>> might include Hierarchical Pull, Publish/Subscribe, or Push models >>>>> and related security extensions). >>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >
- [lisp] Draft of new Proposed Charter Luigi Iannone
- Re: [lisp] Draft of new Proposed Charter Fabio Maino
- Re: [lisp] Draft of new Proposed Charter Albert Cabellos
- Re: [lisp] Draft of new Proposed Charter Luigi Iannone
- Re: [lisp] Draft of new Proposed Charter Luigi Iannone
- Re: [lisp] Draft of new Proposed Charter Fabio Maino
- Re: [lisp] Draft of new Proposed Charter Sharon
- Re: [lisp] Draft of new Proposed Charter Albert Cabellos
- Re: [lisp] Draft of new Proposed Charter Joel M. Halpern
- Re: [lisp] Draft of new Proposed Charter Luigi Iannone
- Re: [lisp] Draft of new Proposed Charter Luigi Iannone
- Re: [lisp] Draft of new Proposed Charter Luigi Iannone
- Re: [lisp] Draft of new Proposed Charter Joel M. Halpern
- Re: [lisp] Draft of new Proposed Charter Fabio Maino
- Re: [lisp] Draft of new Proposed Charter Fabio Maino
- Re: [lisp] Draft of new Proposed Charter Fabio Maino