Re: [lisp] Proposed WG Charter on GitHub

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

Thanks for your comments

Agree with Luigi's comments earlier
See PPE for my comments

On Mon, Oct 9, 2023 at 1:41 PM Dino Farinacci <[e-mail]> wrote:

> > Hi Dino,
> >
> > A few comments inline
> >
> >> On Oct 7, 2023, at 00:54, Dino Farinacci <[e-mail]> wrote:
> >>
> >> Here are my comments. The charter text comes first and is indented and
> my comments follow:
> >>
> >>> LISP Working Group Charter ProposalProposed Charter: Introduction
> >>> LISP supports a routing architecture which decouples the routing
> locators and identifiers, thus allowing for efficient
> >>
> >> "... supports an overlay routing …"
> >
> > Is it really necessary?
>
> Well I think so since we changed the solution space of LISP from "saving
> the routing tables" to a more general overlay solution.
>
> >
> >>> aggregation of the routing locator space and providing persistent
> identifiers in the identifier space. LISP requires no changes to
> end-systems or to routers that do not directly participate in the LISP
> deployment. LISP aims for an incrementally deployable protocol, so new
> features and services can be added easily and quickly to the network using
> overlays. The scope of the LISP technology is potentially applicable to
> have a large span.The LISP WG is chartered to continue work on the LISP
> protocol and produce standard-track documents.
> >>
> >> I would add some of the more explicit features that overlay routing can
> do and how LISP actually has done so and specified at a very detailed
> level. Some examples are mobility, VPNs, multicast, mix protocol family,
> all with the latest in security mechanisms.
> >
> > We are not promoting LISP here, we are listing the work items. Let’s
> keep it simple and to the point.
>
> That is okay, but you did give some basic features as you describe "how it
> works".
>
> >
> >>
> >>> Proposed Charter: Work Items Part 1
> >>>   • 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).
> >>>   • 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.
> >>>   • Multicast Support: LISP support for multicast environments has a
> growing number of use cases. Support for multicast is needed in order to
> achieve scalability. The current documents [Ref to experimental multicast
> RFCs] should be merged and published as Standard Track.
> >>
> >> I think the smaller work items that we can knock out should be in Part
> 1 like geo-coordinates and name-encoding.
> >
> > Geo coordinates is part of the mobility bullet point.
>
> Right, that is misplaced IMO. GPS can be used for mobility but none of the
> mobility drafts that state mechanisms refer to it. Like VPNs and TE, GPS is
> its own category.
>
> PPE - I do think future drafts in mobility will probably reference it
hence its grouping here.

>
> >> And there is no mention of VPN and TE support. It needs to go in
> somewhere.
> >
> > VPN is later on. TE is indeed missing, we need to include it somewhere.
>
> Ack.
>
> >
> >>
> >>> Proposed Charter: Work Items Part 2
> >>>   • Standard Track Documents: The core specifications of LISP have
> been published as “Standard Track” [references]. The WG will continue the
> work of moving select specifications to “Standard Track”.
> >>>   • 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.
> >>
> >> I would not call VPN segmentation as security. I view it more as
> topological member grouping.
> >
> > Which is also used for security purposes.
> >>
>
> Right but goes beyond it.
>

PPE - I see security as a use case but  grouping the draft here does not
imply any restriction on its uses beyond.

>
> >>>   • 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. RFC 7215, 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 RFC 7215.
> >>> Proposed Charter: Tentative Milestones
> >>>   • November 2023: Submit a LISP YANG document to the IESG for
> consideration
> >>>   • March 2024: Submit a LISP NAT Traversal document to the IESG for
> consideration
> >>>   • June 2024: Submit 8111bis to the IESG for consideration
> >>>   • June 2024 : Submit LISP geo-coordinates for consideration
> >>
> >> This, with name-encoding, can get done sooner. We just have to push
> harder.
> >>
> >>>   • November 2024: Submit merged Multicast document to the IESG for
> consideration
> >>
> >> Note, from the previous email you referred to
> "underlay-multicast-trees". That document has changed its name to reflect
> what it really is designing, its titled draft-vdas-lisp-group-mapping-00.
> >
> > As for previous comments we better avoid “merged”, may be just use
> “multicast documentS”.
>
> Ack.
>
> >
> >>
> >>>   • March 2025: Submit 6832bis pXTRs to the IESG for consideration
> >>>   • June 2025: Submit merged LCAFbis to the IESG for considerations
> >>>   • November 2025: Submit LISP Mobile Node to the IESG for
> considerations
> >>>   • March 2026: Submit LISP Applicability document to the IESG for
> considerations
> >>>   • November 2026: Wrap-Up or recharter
> >>
> >> There should be some mention on what to do with the use-case documents.
> Either a spin-off operational working group, or publish as Informational or
> something else.
> >
> > May be we need to be explicit in the “LISP applicability” bullet point
> about informational document.
>
> Right, agree.
>
> >
> >>
> >> And the same for draft-farinacci-lisp-decent, which is the only mapping
> database document on the table. I think its more than a operational
> use-case since there is design mechanisms and algorithms in the
> specification.
> >
> > AFAIR the LISP WG has showed low interest in the decent mapping system,
> that is the reason why there is no explicit mapping system in the charter.
>
> Well I am not sure we have asked. Or at least not yet. And the authors
> have never requested it as a WG document. So use this as a request to adopt
> as WG document? Can you ask the list officially?
>
> Dino
>
>