Here are my comments. See inline.

> On Oct 5, 2022, at 1:39 AM, Luigi Iannone <[email protected]> wrote:
> 
> Hi All,
> 
> Padma and myself did work on an first draft of a possible new charter for the 
> LISP WG.
> 
> We need now input from you about what is missing or what is not there.
> 
> The charter can be found at: 
> https://docs.google.com/document/d/1PbvubD9kXAxqtUCe37n8suC5b-jZ_aGmVv6TAt89VIA/edit
> 
> And also hereafter.
> Please share your thoughts on the mailing list.
> 
> Ciao
> 
> L.
> 2022 Charter for LISP Working Group
> 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.

I would add "LISP aims for an incrementally deployable protocol so new features 
and services can be added easily and quickly to the network using overlays."

> The scope of the LISP technology is potentially applicable to have a large 
> span, including unicast and multicast overlays at Layer 2  as well as at 
> Layer 3, encompassing NAT traversal, VPNs, and supporting mobility as a 
> general feature, independently of whether it is a mobile  user or a migrating 
> Virtual Machine (VM). Hence, the LISP technology is applicable in both Data 
> Centers, public Internet, and global private network environments.

You indicate "both" but have 3 examples. I would restate:

Hence, LISP technology is applicable to run in data centers, the public 
Internet, global private network environments, as well as other infrastructures 
like 3GPP, satellite, ICAO, and LoRA/CATM (IoT) based native infrastructures.

> The LISP WG is chartered to continue work on the LISP protocol and produce 
> standard-track documents. 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.
> In parallel with the previous main work item, the LISP WG will work on the 
> items listed below:
> 
>       • Multi-Protocol Mapping System: 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. By extending LISP with new 
> multi-protocols support, it becomes necessary to develop the required mapping 
> function and control plane extensions to operate LISP map-assisted networks 
> (which might include Hierarchical Pull, Publish/Subscribe, or Push models, 
> independent mapping systems interconnection, security extensions, or 
> alternative transports of the LISP control protocol).
>       • Mobility: Some LISP deployment scenarios include mobile nodes (in 
> mobile environments) or Virtual Machines (VMs in data centers), hence, 
> support needs to be provided in order to achieve seamless connectivity. This 
> work item may benefit from experience of other Working Groups like DMM 
> (Distributed Mobility Management) or NVO3 (for VM migration).
>       • Data-Plane Encryption: In some scenarios, it may be desirable to 
> encrypt LISP encapsulated traffic. In this case, the data-plane encryption 
> mechanism itself and support for control-plane security material exchange 
> needs to be specified. Any solution proposed in this work item has to be 
> reviewed by security experts. 
>       • NAT-Traversal: Support for NAT-traversal solution in deployments 
> where LISP tunnel routers are separated from correspondent tunnel routers by 
> a NAT (e.g., LISP mobile node).
>       • Models for managing the LISP protocol and deployments that include 
> data models, OAM, as well as allowing for programmable management interfaces. 
> These management methods should be considered for both the data-plane, 
> control plane, and mapping system components of standards-track documents.

I would add this because its very important:

o New ways to scale and secure the LISP protocol and its deployment use-cases 
as more operational experience is obtained.

> Documents for these work items will as well target standard-track unless the 
> document is of a different maturity level (e.g., Informational or 
> Experimental). In the latter case, the Working Group will evaluate the 
> maturity level and propose a recommended track for the document.
> 
> Collaboration with other working groups, as stated in the different work 
> items (e.g., PIM, NVO3, DMM, SFC), is important

Add mboned, intarea, rtgwg IMO, and arguably saag.

Dino

_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to