Additional comments/suggestions Milestones To be consistent, we should have at least a milestone for each of the larger sections. There is a couple missing: - TE section - suggest March 2025 - Privacy and Security section - suggest Nov 2025 or March 2026
Format To be consistent with other sections, we should have "Yang Model:" format. Ordering I would not propose to order as sections matching the milestones as sections may have different documents at different maturity levels. However this one caught my attention: should we move up "NAT transversal" section to after "Yang Model:" as it is in March 2024. Thanks Padma On Fri, Oct 13, 2023 at 10:21 AM Padma Pillay-Esnault <[email protected]> wrote: > Hi Luigi > > Looks good to me > nit/suggestion below see PPE > > Padma > > On Fri, Oct 13, 2023 at 2:05 AM Luigi Iannone <[email protected]> wrote: > >> 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]). >> >> PPE - Reading this the "standard track document" bullet kinda implies > that the docs below are not standard track. > Suggestion - "Moving to Standard tracks:" > > > >> >> - >> >> 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) < >> [email protected]> 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 <[email protected]> >> *Date: *Sunday, October 1, 2023 at 7:46 PM >> *To: *LISP mailing list list <[email protected]> >> *Cc: *[email protected] <[email protected]> >> *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 >> >> >>
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
