Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]

[Padma Pillay-Esnault <[e-mail]>]

Hi Dino

Thank you for the comments.

What do you think of putting some major milestones for mobility and
security sections rather than per document?

Padma



On Mon, Oct 16, 2023 at 12:31 PM Dino Farinacci <[e-mail]> wrote:

> Looking at what you put earlier versus later is not based on the reality
> of the readiness of the documents. Here are some comments:
>
> (1) Nov 2023 should be Submit Name-Encoding to IESG.
> (2) Geo-Coordinates has been stable for a long time where NAT-traversal is
> so far from ready. The June date for NAT-traversal is too aggressive.
> Geo-Coordinates should be Nov 2023.
> (3) There is no mention of the VPN document. That too has been running for
> a decade and stable. That should be submitted Nov 2023 or at least Mar 2024.
> (4) What about the other mobility drafts that go along with LISP Mobile
> Node?
> (5) What about the security drafts?

Seems the list below is not complete to me.
>
> Dino
>
> > On Oct 16, 2023, at 6:52 AM, Luigi Iannone <[e-mail]> wrote:
> >
> > 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 <[e-mail]>
> 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 <
> [e-mail]> wrote:
> >> Hi Luigi
> >>
> >> Looks good to me
> >> nit/suggestion below see PPE
> >>
> >> Padma
> >>
> >> On Fri, Oct 13, 2023 at 2:05 AM Luigi Iannone <[e-mail]> 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) <
> [e-mail]> 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 <[e-mail]>
> >>> Date: Sunday, October 1, 2023 at 7:46 PM
> >>> To: LISP mailing list list <[e-mail]>
> >>> Cc: [e-mail] <[e-mail]>
> >>> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lisp
>
>