Hi Luigi, It does not since no changes have been made related to my DISCUSS comments.
Please let me know if f2f discussion can help. Thanks, Ketan On Wed, 23 Jul, 2025, 5:00 pm Luigi Iannone, <g...@gigix.net> wrote: > Hi Ketan, > > A new revision of this document is now available > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-geo-18 > > Can you tell us if it addresses you concerns? > > Thanks > > Luigi > > On 17 Jun 2025, at 21:36, Dino Farinacci <farina...@gmail.com> wrote: > > 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
