Hi Dino, My comments inline.
> On Oct 9, 2023, at 22:41, Dino Farinacci <[email protected]> wrote: > >> Hi Dino, >> >> A few comments inline >> >>> On Oct 7, 2023, at 00:54, Dino Farinacci <[email protected]> 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 > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
