Re: [lisp] Draft of new Proposed Charter

[Luigi Iannone <[e-mail]>]

Hi Albert

I may agree with you in what can be done and what is interesting, but…..

At this point it looks to me (personal opinion) as a bit premature to add such kind of working item.
It looks like we are still at very early stage where we still look what kind of solution would be the best fit.

Or have you more precise ideas?

ciao

L.


> On 15 Oct 2015, at 00:10, Albert Cabellos <[e-mail]> wrote:
> 
> 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
>>