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
