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 <farina...@gmail.com> wrote: > > Hi Dino, > > > > A few comments inline > > > >> On Oct 7, 2023, at 00:54, Dino Farinacci <farina...@gmail.com> 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 > >
_______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
