[lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]

[Luigi Iannone <[e-mail]>]

Hi,

I’ve tried to merge the list of work items in the charter in a single list and created a PR.


Items have been merged and re-ordered in the following way:

First the general standard track work item (multicast work merged here)

Then other work with drafts more advanced appearing earlier.

Milestone list will be updated once WG converged on this part.


The list looks like:

Main work items are identified as follows:

Standard Track Documents: The core specifications of LISP have been published as “Standard Track” ([RFC9300], [RFC9301]). The WG will continue the work of moving select specifications to “Standard Track” (e.g., [RFC8060], [RFC8111] and the set of multicast documents like [RFC6831] and [RFC8378]).

YANG 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.

Map Server Reliable Transport: LISP control plane messages are transported over UDP, however, in some cases, the use of a reliable transport protocol is a better fit, since it actually helps reduce periodic signaling.

LISP for traffic engineering: Specifics on how to do traffic engineering on LISP deployments could be useful. For instance, encode in a mapping not only the routing locators associated to EIDs, but also an ordered set of re-encapsulating tunnel routers used to specify a path.

LISP external connectivity: [RFC6832] defines the Proxy ETR element, to be used to connect LISP sites with non-LISP sites. However, LISP deployments could benefit from more advanced internetworking, for instance by defining mechanism to discover such external connectivity.

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).

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.

Privacy and Security: The WG will work on topics of EID anonymity, VPN segmentation leveraging on the Instance ID, and traffic anonymization. The reuse of existing mechanisms will be prioritized.

LISP Applicability: In time, LISP has proved to be a very flexible protocol that can be used in various use-cases not even considered during its design phase. [RFC7215], while remaining a good source of information, covers one single use case, which is not anymore the main LISP application scenario. The LISP WG will document LISP deployments for most recent and relevant use-cases so as to update [RFC7215].



Does it look as an acceptable trade-off among the various comments received?

Ciao

L.

> On Oct 11, 2023, at 14:33, Alberto Rodriguez-Natal (natal) <[e-mail]> wrote:
> 
> Hi all,
>  
> A few thoughts on the charter after going through the latest revision and the discussion on this thread.
>  
> * We have a milestone for LCAFbis, but LCAF is not mentioned in the work items. Is LCAF supposed to be covered by the “Standards Track Documents” work item? Same for DDT. If so, I would mention them as examples of possible “Standards Track Documents”. Also, I agree with Padma that we should extend the work item to include “language to cover incremental features, behaviors and specifications”.
>  
> * I think the external connectivity work item could be generalized to cover both the external-connectivity draft as well as any other work adjacent to 6832, for instance something like:
>  
> “LISP Internetworking: [RFC6832] defines the Proxy ETR element, to be used to connect LISP sites with non-LISP sites. However, LISP deployments could benefit from more advanced internetworking, for instance by defining mechanism to discover such external connectivity.”
>  
> * Similar comment for TE. I think we could be more general, something like:
>  
> “Traffic Engineering and LISP: Specifics on how to do traffic engineering on LISP deployments could be useful, for instance some use cases…”
>  
> * On the milestones section, I think LCAFbis could be done much sooner. Also, I agree with Dino we should have name-encoding sooner as well (this is partly my fault, I’m halfway on my shepherds writeup, will try to close on that).
>  
> * Based on the discussion on San Francisco, it is not entirely clear to me the consensus of the WG regarding “Submitting a LISP Applicability document to the IESG”. Would it be possible to leave this milestone somehow more open?
>  
>  
> I’m also planning to send a PR on GitHub with some editorial comments.
>  
> Thanks,
> Alberto
>  
> From: Padma Pillay-Esnault <[e-mail]>
> Date: Sunday, October 1, 2023 at 7:46 PM
> To: LISP mailing list list <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> Subject: Proposed WG Charter on GitHub
> 
> Hello all,
>  
> We have created a repository to gather input for the proposed LISP WG charter presented in our last meeting.
>  
> A pointer to the repo below
> https://github.com/lisp-wg/wg-charter
>  
> We welcome your comments and contributions.
>  
> Thanks
> Padma and Luigi