Re: [lisp] Proposed WG Charter on GitHub

[Luigi Iannone <[e-mail]>]

Hi Dino,

A few comments inline

> On Oct 7, 2023, at 00:54, Dino Farinacci <[e-mail]> wrote:
> 
> Here are my comments. The charter text comes first and is indented and my comments follow:
> 
>> LISP Working Group Charter ProposalProposed Charter: Introduction
>> LISP supports a routing architecture which decouples the routing locators and identifiers, thus allowing for efficient
> 
> "... supports an overlay routing …"

Is it really necessary?

> 
>> 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, 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.The LISP WG is chartered to continue work on the LISP protocol and produce standard-track documents.
> 
> I would add some of the more explicit features that overlay routing can do and how LISP actually has done so and specified at a very detailed level. Some examples are mobility, VPNs, multicast, mix protocol family, all with the latest in security mechanisms.

We are not promoting LISP here, we are listing the work items. Let’s keep it simple and to the point.

> 
>> Proposed Charter: Work Items Part 1
>>    • 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).
>>    • 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.
>>    • Multicast Support: LISP support for multicast environments has a growing number of use cases. Support for multicast is needed in order to achieve scalability. The current documents [Ref to experimental multicast RFCs] should be merged and published as Standard Track.
> 
> I think the smaller work items that we can knock out should be in Part 1 like geo-coordinates and name-encoding.

Geo coordinates is part of the mobility bullet point.

> And there is no mention of VPN and TE support. It needs to go in somewhere.

VPN is later on. TE is indeed missing, we need to include it somewhere. 

> 
>> Proposed Charter: Work Items Part 2
>>    • Standard Track Documents: The core specifications of LISP have been published as “Standard Track” [references]. The WG will continue the work of moving select specifications to “Standard Track”.
>>    • 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.
> 
> I would not call VPN segmentation as security. I view it more as topological member grouping.

Which is also used for security purposes. 
> 
>>    • 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. RFC 7215, 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 RFC 7215.
>> Proposed Charter: Tentative Milestones
>>    • November 2023: Submit a LISP YANG document to the IESG for consideration
>>    • March 2024: Submit a LISP NAT Traversal document to the IESG for consideration
>>    • June 2024: Submit 8111bis to the IESG for consideration
>>    • June 2024 : Submit LISP geo-coordinates for consideration
> 
> This, with name-encoding, can get done sooner. We just have to push harder.
> 
>>    • November 2024: Submit merged Multicast document to the IESG for consideration
> 
> Note, from the previous email you referred to "underlay-multicast-trees". That document has changed its name to reflect what it really is designing, its titled draft-vdas-lisp-group-mapping-00.

As for previous comments we better avoid “merged”, may be just use “multicast documentS”.

> 
>>    • March 2025: Submit 6832bis pXTRs to the IESG for consideration
>>    • June 2025: Submit merged LCAFbis to the IESG for considerations
>>    • November 2025: Submit LISP Mobile Node to the IESG for considerations
>>    • March 2026: Submit LISP Applicability document to the IESG for considerations
>>    • November 2026: Wrap-Up or recharter
> 
> There should be some mention on what to do with the use-case documents. Either a spin-off operational working group, or publish as Informational or something else.

May be we need to be explicit in the “LISP applicability” bullet point about informational document.

> 
> And the same for draft-farinacci-lisp-decent, which is the only mapping database document on the table. I think its more than a operational use-case since there is design mechanisms and algorithms in the specification.

AFAIR the LISP WG has showed low interest in the decent mapping system, that is the reason why there is no explicit mapping system in the charter. 

Ciao

L.



> 
> Dino
> 
>> On Oct 3, 2023, at 5:14 PM, Alvaro Retana <[e-mail]> wrote:
>> 
>> Hi!
>> 
>> In general, I like the charter.  However, I have some questions/comments:
>> 
>> (1) What’s the difference between the work items in “Part 1” and the ones in “Part 2”?
>> 
>> (2) Related.  I’m assuming that the headers “Proposed Charter…” will be deleted.
>> 
>> (3) Multicast support. It’s not clear from the description if the work is just to merge the experimental RFCs or if there’s something else. ?
>> 
>> (4) LISP Applicability.  How will "the most recent and relevant use-cases” be determined?  I don’t think we need to answer, but the question may come up later in the process.
>> 
>> (5) Maybe reorder the work items to coincide with the order of the milestones.
>> 
>> (6) "LISP geo-coordinates” doesn’t map to a work item.
>> 
>> 
>> I don’t have write access to the repo, so I’m attaching diffs with some editorial points.
>> 
>> 
>> Thanks!
>> 
>> Alvaro.
>> 
>> On October 1, 2023 at 1:46:22 PM, Padma Pillay-Esnault ([e-mail]) wrote:
>>> 
>>> 
>>> 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
>>> _______________________________________________ 
>>> lisp mailing list 
>>> [e-mail] 
>>> https://www.ietf.org/mailman/listinfo/lisp
>> <ad28c1db-4fd7-440d-acc8-eae8bbb99a7e.html>_______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp
> 
>