Re: [lisp] Draft of new Proposed Charter

[Fabio Maino <[e-mail]>]

On 10/15/15 7:10 AM, Albert Cabellos 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…)
>>

I think it might be interesting to explore the options the we might have 
here. While we expand the scope of LISP beyond mapping EID to RLOCs (see 
the LISP/NSH draft as an example), we'll indeed have to deal with a 
bunch of new LCAF types. A language might help to keep focus on the 
semantic, rather than on the syntax of allocating bits.  I see no harm 
in including this work with the goal to write an experimental RFC.


Fabio


> 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
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp