Good points Padma,
What about the following ordering? 1. November 2023: Submit a LISP Yang model document to the IESG for consideration 2. March 2024: Submit LISP Traffic Engineering document to the IESG for consideration 3. March 2024: Submit LISP Reliable Transport document to the IESG for consideration 4. June 2024 : Submit LISP geo-coordinates for consideration 5. June 2024: Submit a LISP NAT Traversal document to the IESG for consideration 6. November 2024: Submit 8111bis to the IESG for consideration 7. November 2024: Submit merged LCAFbis document to the IESG for consideration 8. March 2025: Submit LISP Privacy and Security documents to the IESG for consideration 9. March 2025: Submit 6832bis Proxy XTRs document to the IESG for consideration 10. June 2025: Submit LISP Mobile Node to the IESG for consideration 11. November 2025: Submit Multicast documents to the IESG for consideration 12. March 2026: Submit LISP Applicability document to the IESG for consideration 13. November 2026: Wrap-Up or recharter L. > On Oct 13, 2023, at 19:49, Padma Pillay-Esnault <[email protected]> wrote: > > 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] > <mailto:[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] >> <mailto:[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] <mailto:[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] >>>> <mailto:[email protected]>> >>>> Date: Sunday, October 1, 2023 at 7:46 PM >>>> To: LISP mailing list list <[email protected] <mailto:[email protected]>> >>>> Cc: [email protected] <mailto:[email protected]> >>>> <[email protected] <mailto:[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
