Re: [lisp] Draft of new Proposed Charter

[Fabio Maino <[e-mail]>]

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