Hi Luigi Looks good to me nit/suggestion below see PPE
Padma On Fri, Oct 13, 2023 at 2:05 AM Luigi Iannone <g...@gigix.net> 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) < > na...@cisco.com> 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 <padma.i...@gmail.com> > *Date: *Sunday, October 1, 2023 at 7:46 PM > *To: *LISP mailing list list <lisp@ietf.org> > *Cc: *lisp-cha...@ietf.org <lisp-cha...@ietf.org> > *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 lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
