Re: [lisp] Update Proposed CHarter

[Fabio Maino <[e-mail]>]

Hi Luigi,
it looks good to me.

One item that was mentioned at the last meeting was to include the work 
done so far on map server reliable transport.

One possible way to include it is to change the very last bullet to 
something like:

- Alternative Mapping System Design. By extending LISP with  new 
protocols support it is also necessary to develop the required mapping 
function extensions to operate LISP map-assisted  networks (which might 
include Hierarchical Pull, Publish/Subscribe, or Push models and related 
security extensions, *or alternative transports of the LISP control 
protocol*).

Thanks,
Fabio





On 1/4/16 4:44 AM, Luigi Iannone wrote:
> Hi and Happy 2016 to All,
>
> time to restart our WG activity in this new year. ;-)
>
> We tried to include all comments received via mail and stated during the last meeting in Japan into an updated charter.
> Changes are relatively minor, showing that the WG has almost converged to a proposal.
> Yet, before pushing the new charter to the IESG for approval, we would like to have a last short iteration in the WG.
> Hereafter you can find the updated text.
>
> If the text looks good for you, please state so in the mailing list.
>
> If you think something is missing or can be improved, please state so in the mailing list.
>
> Thanks
>
> Joel and Luigi
>
>
> %%%%%%%% Updated Proposed Charter %%%%%%%%%%%%%%%%%%%%%%%%
>
> 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 techology is recognized to range
> from unicast and multicast overlays at Layer 2 as well
> as at Layer 3, including NAT traversal, VPNs, and
> supporting mobility as a general feature, independently
> of wheter 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 experimental
> documents.
>
> Beside this main focus, the LISP WG 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.
>
> -       Models for managing the LISP protocol and deployments
>          that include data models, as well as allowing for
>          programmable management interfaces. These managament
>          methods should be considered for both the data-plane,
>          control-plane, and mapping system components
>
> -       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 Grops such as  NVO3 and SFC.
>
> -       Alternative Mapping System Design. By extenting LISP
>          with  new protocols support it is also necessary to
>          develop the required mapping function extensions to
>          operate LISP map-assisted  networks (which might
>          include Hierarchical Pull, Publish/Subscribe, or Push
>          models and related security extension).
>
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp