Ketan Talaulikar has entered the following ballot position for draft-ietf-lisp-geo-15: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-geo/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There is one particular aspect in the draft that I would like to discuss to understand better since the document is not very clear about this usage: There is the following text in the document (using idnits output of v15) about the use cases: 148 4. Relevant Use Cases 150 4.1. Geo-Points in RLOC-records 152 Geo-Points can accompany an RLOC-record to determine the physical 153 location of an ETR or RTR. This can aid in determining geographical 154 distance when topological distance is inaccurate or hidden. and then ... 195 A Geo-Prefix, when encoded in an EID-record, could be registered as 196 an EID-prefix and when a Geo-Point is used as an EID lookup key, a 197 sort of longest match could be looked up. If the Geo-Point is in the 198 Sphere described by the Geo-Prefix, an entry is returned to the Map- 199 Requestor. 201 When a Geo-Point EID is looked up in the mapping system, what is 202 returned is the longest prefix match. In this context, what is 203 returned is the Geo-Prefix with the largest radius value, which 204 corresponds to the largest physical area. If the Geo-Point supplied 205 in a Map-Request has a mask-length/radius which is smaller than what 206 is registered for any matching Geo-Prefix in the mapping system, then 207 all Geo-Prefixes are returned. This uses the same overlapping lookup 208 semantics defined in [RFC9301] for IP address EIDs. <discuss> Both of these seem to go beyond a typical "descriptive" use-case and get into the realm of a specification. The aspects about geographical distance (no clear specification on how this is measured from the geo coordinates) being used by LISP instead of the underlying topological distance (i.e., routing protocol metric/cost?) seems like a protocol behavior change to me. The same goes for the "longest prefix match" in the mapping system. Are the details of these behaviors not something that need to be specified by this document? ---------------------------------------------------------------------- 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? 2) I support Med's DISCUSS on consistency of identification/characterization of a geo-point across various IETF specifications. Not everything is suitable for signaling via routing protocols (assuming there are good use-cases to do so in the first place), but at least it should be a subset of what was in RFC9179? I don't know enough to determine if that is the case. Can this document add a reference to RFC 9179 and explain the relationship of the proposed encoding with its structure? Other comments/suggestions: a) Please consider removing all references to other routing protocols individual drafts that have expired. I think this document needs to make its case independently and the format needs alignment with what is specified in the IETF. FWIW, geo-coordinates were already there in RFC 8060 so there doesn't need to be a justification for why they are needed in the protocol beyond what was said in RFC 8060. b) I suggest a terminology section OR expand on first use for the acronyms and LISP terms in this document. More importantly, provide references to the LISP spec (mostly RFC9300, 9301?) for those terms. c) As a continuation of my discuss point, please consider if there needs to be use-case documentation beyond what was already covered in RFC 8060. Removal of the extra use-case text would be one way to address the comments that I raised in the DISCUSS position. d) I would suggest to add to the introduction section that the reason for this document's experimental status is because it is updating an experimental RFC. _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
