Hi Lars, Thanks for sharing your comments. Please see inline.
> On Nov 30, 2023, at 13:58, Lars Eggert via Datatracker <[email protected]> > wrote: > > Lars Eggert has entered the following ballot position for > charter-ietf-lisp-04-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-lisp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # GEN AD review of charter-ietf-lisp-04-04 > > CC @larseggert > > ## Comments > > ### "LISP", paragraph 1 > ``` > - 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 (RTRs) used to specify a path. > ``` > "Could be useful" is a pretty weak motivator. Does anyone want > to *deploy* this? If not, does it deserve to be a work item? This is indeed a weak formulation. The work is already being implemented and used. Let’ change it in “…. Is a useful feature”. > > ### "LISP", paragraph 0 > ``` > - NAT-Traversal: Support for a NAT-traversal solution in deployments where > LISP > tunnel endpoints are separated from by a NAT (e.g., LISP mobile node). Tha should be better phrased as “endpoints are behind a NAT…" > ``` > Stick it into UDP and use existing NAT traversal solutions. > Re-engineering all that does not seem worthwhile. Unfortunately there are peculiarities in LISP that do not make existing solution directly applicable (mostly for the control plane). However, The document is not about new NAT traversal method, rather what changes in the LISP control plane messages are necessary to make LISP work behind a NAT. Should we just say “support for NAT”? Since we are not inventing a new NAT-traversal technology. > > ### "LISP", paragraph 2 > ``` > - 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 internet-working, for instance by defining > mechanisms to discover such external connectivity. > ``` > "Could benefit" is a pretty weak motivator. Does anyone want > to *deploy* this? If not, does it deserve to be a work item? It is the same case like LISP-TE. There is a document and an implementation. What about “advanced internet-working solution bring clear benefits to LISP deployments…” What do you think? > > ### "LISP", paragraph 1 > ``` > - Mobility: Some LISP deployment scenarios include endpoints that move across > different LISP xTRs and/or LISP xTRs that are themselves mobile. Support > needs > to be provided to achieve seamless connectivity. > ``` > "Some deployment scenarios include it" is a pretty weak motivator. > Does anyone want to *deploy* this? If not, does it deserve to be a work item? > The some was referred to the fact that LISP deployment may or may not include mobile nodes, when they do endpoints as well as xTRs may be mobile. What about: "- Mobility: LISP deployments include mobility where endpoints can move across different LISP xTRs and/or LISP xTRs can themselves be mobile." Does it sound better? Ciao L. > ## Notes > > This review is in the ["IETF Comments" Markdown format][ICMF], You can use the > [`ietf-comments` tool][ICT] to automatically convert this review into > individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > [ICT]: https://github.com/mnot/ietf-comments > [IRT]: https://github.com/larseggert/ietf-reviewtool > > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
