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 <[email protected]> wrote: > > I have submitted -17, FYI. > > Dino > >> On Jun 17, 2025, at 5:55 AM, Ketan Talaulikar <[email protected]> wrote: >> >> Hi Dino, >> >> Please check inline below for follow-up with KT2. >> >> >> On Fri, Jun 6, 2025 at 7:24 PM Dino Farinacci <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
