Thanksf or your comments Ketan. See responses inline. > <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?
This is not a use-case document. It IS a protcol specification but includes use-cases. > ---------------------------------------------------------------------- > 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. > 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? I believe I addressed this. If you think not, be more specific. > 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. I made changes to reflect Med's comments. > 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. I will add a paragraph, like we did for draft-ietf-lisp-te based on the same commentary. That is refer to RFC9300. I will also expand the acroymns when used for the first time. > 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. I believe not. > 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. The design is not expermental since it has been implemented in multiple implementation. What is "experimental" is the status of the document. You have to get WG and chairs to decide "how experimental" this draft is. Its an administracive issue and not a technical one. Thanks, Dino _______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
