> 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. > > > ---------------------------------------------------------------------- > > 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. Dino _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
