Re: [lisp] Draft of new Proposed Charter

[Albert Cabellos <[e-mail]>]

Hi Luigi

Please see my comments inline:

On Wed, Oct 14, 2015 at 1:31 AM, Luigi Iannone <[e-mail]> 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 <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>
>>>
>>> _______________________________________________
>>> lisp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lisp
>>
>> _______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp
>