I have submitted -17, FYI. Dino
> On Jun 17, 2025, at 5:55 AM, Ketan Talaulikar <ketant.i...@gmail.com> wrote: > > Hi Dino, > > Please check inline below for follow-up with KT2. > > > On Fri, Jun 6, 2025 at 7:24 PM Dino Farinacci <farina...@gmail.com> wrote: > > > 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. > > You need geo distance when you may be testing for wireless signal range. > Where topologically, at layer-2 or layer-3 is not relevant. We are also using > geo-coordinates to locate things or to keep inventory of things. > > > 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? > > From a Geo-prefix, you build a sphere. If the geo-point is not inside of the > sphere, you can determine something like "this device is not in San > Francisco". So pick any point on the surface of the sphere and calculate the > distance between the geo-point and any point on the sphere. To calculate > distacne, see next paragraph. > > When you want to know the distance between two points, there are geo > libraries tht compute it based on roughly 100km going north and south > (depending how close the points are to the equator) and same for longatude > for east-west direction. > > The unit distance is kilometers. > > KT2> Let me take a step back. Getting Geo-Prefixes in EID and RLOC records > looks to me as a protocol specification and not a use-case. Making map > requests for these records and the map server returning the information > (using physical distance) is also a protocol behavior specification - not a > use-case. Therefore, I find all of this being under a "use-case" section as > misleading and I am checking why this isn't covered as a specification - > beyond just the encoding. Furthermore, "there are geo libraries that compute" > does not seem to fully specify how this works - we'll need some references > that point to how this calculation works or it can be specified inline. Are > there any interoperability considerations here if different components of the > LISP control plane were to interpret or compute these distances in a > different way? > > > > > > ---------------------------------------------------------------------- > > > 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. > > It is beacuse we added more features to the encoding. Like cm granularity and > radius to support Geo-Prefixes. ZSo the 8060 version is obsolete and hence we > created a new code point in this document. > > KT> Great. Could you please also add that as the reason for making the change > over proposal in RFC 8060 (as opposed to the current consistency argument > across routing protocols)? > > Thanks, > Ketan > > > Dino > > _______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
