[RTG-DIR]Re: Rtgdir early review of draft-ietf-lisp-geo-06

[Ines Robles <[e-mail]>]

Hello Dino,

Thank you for addressing my comments, please find my answers below

On Fri, Jun 7, 2024 at 2:53 AM Dino Farinacci <[e-mail]> 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.

>
>