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

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

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
>>
>>
>>