Re: [lisp] Proposed WG Charter on GitHub

[Luigi Iannone <[e-mail]>]

Hi Dino,

My comments inline.

> On Oct 9, 2023, at 22:41, Dino Farinacci <[e-mail]> wrote:
> 
>> 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?
> 
> Well I think so since we changed the solution space of LISP from "saving the routing tables" to a more general overlay solution.

Added in the PL just submitted.

> 
>> 
>>>> 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.
> 
> That is okay, but you did give some basic features as you describe "how it works".

We do not need to be exhaustive here ;-)

> 
>> 
>>> 
>>>> 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.
> 
> Right, that is misplaced IMO. GPS can be used for mobility but none of the mobility drafts that state mechanisms refer to it. Like VPNs and TE, GPS is its own category.

I agree with the point made by Padma in her reply; putting geo coordinates in the mobility group does not limit its application to mobility.

Ciao

L.


> 
>> 
>>> 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.
> 
> Ack.
> 
>> 
>>> 
>>>> 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.
>>> 
> 
> Right but goes beyond it.

And like for the geo coordinates and TE you can use it beyond that scope.


> 
>>>>  • 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”.
> 
> Ack.
> 
>> 
>>> 
>>>>  • 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.
> 
> Right, agree.
> 
>> 
>>> 
>>> 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.
> 
> Well I am not sure we have asked. Or at least not yet. And the authors have never requested it as a WG document. So use this as a request to adopt as WG document? Can you ask the list officially?
> 
> Dino
>