Hi Dino, Thanks for posting that update. Please check inline below for response/clarification.
On Fri, Jun 6, 2025 at 1:37 AM Dino Farinacci <farina...@gmail.com> wrote: > Thanksf or your comments Ketan. See responses inline. > > > <discuss> Both of these seem to go beyond a typical "descriptive" > use-case and > > get into the realm of a specification. The aspects about geographical > distance > > (no clear specification on how this is measured from the geo > coordinates) being > > used by LISP instead of the underlying topological distance (i.e., > routing > > protocol metric/cost?) seems like a protocol behavior change to me. The > same > > goes for the "longest prefix match" in the mapping system. Are the > details of > > these behaviors not something that need to be specified by this document? > > This is not a use-case document. It IS a protcol specification but > includes use-cases. > KT> Looks like my comment was not clear. I am asking for a more detailed specification of the mechanics that you are referring to in the use-cases. Let us take an example: This can aid in determining geographical distance when topological distance is inaccurate or hidden. KT> How is this geographical distance exactly calculated? Any reference? If not please specify. What is the unit of distance used? Does the document propose to change the route calculation to shift from the topological distance (coming from say underlying IGP?) to this geographical distance now? > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Please also find below some comments on this document: > > > > Support of other DISCUSS positions: > > > > 1) I support Deb's DISCUSS position related to the reference to > OSPF/ISIS/BGP > > individual drafts that carry similar extensions. Those documents have > expired > > several years ago. None of them were adopted by their respective WGs - > > presumably due to lack of interest by the community? The case for > changing > > existing LISP extensions for geo-coordinates (also an experimental > RFC8060 > > section 4.3) for the (sole?) reason of bringing consistency across > routing > > protocols does not look sound to me. Were there any > implementations/deployments > > of the encoding of RFC8060 that necessitate this change? > > I hope Deb can accept Med's comments so I made changes to reflect those. > KT> That text change looks good to me. However, the justification of changing the encoding that was in RFC8060 is not captured in this document and that is what I am looking for. The point of consistency with other protocols is moot (IMHO) since they don't exist today and those protocols might as well use RFC8060 encoding (if/when someone really picks that up) if consistency is all that we need. I hope you get my point. > > > 2) I support Med's DISCUSS on consistency of > identification/characterization of > > a geo-point across various IETF specifications. Not everything is > suitable for > > signaling via routing protocols (assuming there are good use-cases to do > so in > > the first place), but at least it should be a subset of what was in > RFC9179? I > > don't know enough to determine if that is the case. Can this document > add a > > reference to RFC 9179 and explain the relationship of the proposed > encoding > > with its structure? > > I believe I addressed this. If you think not, be more specific. > KT> I will let you work with Med on this > > > Other comments/suggestions: > > > > a) Please consider removing all references to other routing protocols > > individual drafts that have expired. I think this document needs to make > its > > case independently and the format needs alignment with what is specified > in the > > IETF. FWIW, geo-coordinates were already there in RFC 8060 so there > doesn't > > need to be a justification for why they are needed in the protocol > beyond what > > was said in RFC 8060. > > I made changes to reflect Med's comments. > KT> Please see my clarification above. > > > b) I suggest a terminology section OR expand on first use for the > acronyms and > > LISP terms in this document. More importantly, provide references to the > LISP > > spec (mostly RFC9300, 9301?) for those terms. > > I will add a paragraph, like we did for draft-ietf-lisp-te based on the > same commentary. That is refer to RFC9300. I will also expand the acroymns > when used for the first time. > KT> Thank you. > > > c) As a continuation of my discuss point, please consider if there needs > to be > > use-case documentation beyond what was already covered in RFC 8060. > Removal of > > the extra use-case text would be one way to address the comments that I > raised > > in the DISCUSS position. > > I believe not. > KT> OK - I will wait for the clarifications in the use-cases themselves. > > > d) I would suggest to add to the introduction section that the reason > for this > > document's experimental status is because it is updating an experimental > RFC. > > The design is not expermental since it has been implemented in multiple > implementation. What is "experimental" is the status of the document. You > have to get WG and chairs to decide "how experimental" this draft is. Its > an administracive issue and not a technical one. > KT> For this as well as future documents, I would strongly urge the WG to consider changing the track from experimental to standards track for all LISP RFCs that have implementation (and ideally deployment) experience. I don't have the history on the original experimental status but I note that base LISP specs are standards track now. KT> If there are zero document changes, then there is a simpler process to change from experimental to standards track that BIER followed. See https://www.rfc-editor.org/info/rfc8279. KT> I request Jim to please check on this with the WG chairs. Note that I am not suggesting to hold/block this document until then. Thanks, Ketan > > Thanks, > Dino > > >
_______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
