Hello Dino, Thank you for addressing my comments, please find my answers below
On Fri, Jun 7, 2024 at 2:53 AM Dino Farinacci <farina...@gmail.com> wrote: > > Suggestions/Issues: > > > > It would be nice to add information about: > > > > 1- The document mentions compatibility with OSPF, IS-IS, and BGP. It is > > suggested to provide examples of how LISP with geo-coordinates > interoperates > > with these protocols. > > LISP does not interoperate directly with these protocols. The text > indicates the geo-coordinate packet format is the same to adhere to a more > holistic consistency. > Ok, thanks > > > 2- The draft doesn't mention which LISP messages the geo-coordinates > encoding > > should be used in. It is suggested to add explicitly in which LISP > messages > > (such as Map-Register?) the geo-coordinates encoding should be used, to > provide > > clearer guidance for implementers and newcomers. > > They are the messages that contain EID-records and RLOC-records. I put in > a reference to rfc9301. > Ok, thanks > > > 3- How the geo-coordinates encoding will interoperate with existing LISP > > deployments, including any backward compatibility issues. > > Added a new section. > Ok, thanks > > > 4- How to handle errors such as invalid geo-coordinate data or missing > fields. > > Fixed in the section 5. > Ok, thanks > > > 5- The performance impact of including geo-coordinates in LISP messages, > such > > as increased message size and processing overhead. > > Did not add this. There is no impact. > Ok, thanks > > > 6- Are the geo-coordinates incorporated in control plane operations? > > Yes. RFC9301 and RFC8060 references make this clear. > Ok, thanks > > > 7- Perhaps to include some Manageability Considerations? > > For what? All the management of this new type or any type is in RFC9301. > Ok, Noted. Including a statement in the document that refers readers to RFC9301 for manageability considerations could be useful for completeness. However, I am okay with it either way. > > > 8- How geo-coordinates can aid in selecting alternate paths and improving > > network resilience. how geo-coordinates could help manage dynamic and > mobile > > topologies. > > We have already provided the use-cases we intend to support. There is no > plans to add new features. > Ok, thanks > > > 9- In the security considerations, what about add description on attacks > > related to geo-coordinates such as location spoofing? > > We had added that from previous reviews. Tell us exactly what you are > looking for. > Ok, thanks. I was wondering about potential consequences of location spoofing within the LISP environment, such as misleading network path selection. What do you think? > > Nits: > > > > 10 - Abstract: "Geo-Coordinates can used in..." -> "Geo-Coordinates can > be used > > in ..." 11 - Introduction: "...introduces two..." -> "...introduce > two..." 12 - > > Section 4.2: "... in any on the inner ..." -> "... in any of the inner > ..." 13 > > - Sometimes "Geo-Coordinates" is used and sometimes "geo-coordinates". > > Suggestion to use one format. 14 - Suggestion to expand on First use the > > acronyms: LISP, LCAF, ETR and RTR. 15 - Add a caption for the LCAF > encoding > > figure and an introductory sentence to introduce the figure. 16- In the > LCAF > > encoding figure, two AFI fields are depicted. Add a description for each > one. > > For example, "The AFI field is set to 16387 to indicate that the address > is > > using the LCAF format." And for the other AFI, "The AFI field indicates > the > > Address Family Identifier for the following address...?" Also, add an > > explanation for the Address field. > > Made all these changes. It was alraedy commented to not redefine the terms > so hence not expanded. > Ok, thanks > > > Thanks for this document, > > Thanks again for the review, > Thank you, Ines. > >
_______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
