HI Ketan, Thanks .
I am avaiable at the coffee break this morning. Let me know if you have time. Ciao L. > On 24 Jul 2025, at 17:58, Ketan Talaulikar <[email protected]> wrote: > > 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, <[email protected] > <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I have submitted -17, FYI. >>> >>> Dino >>> >>>> On Jun 17, 2025, at 5:55 AM, Ketan Talaulikar <[email protected] >>>> <mailto:[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] >>>> <mailto:[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]
