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

[Luigi Iannone <[e-mail]>]

Hi Ines,

Did you get the opportunity to check the latest revision of the lisp-geo document? Do you consider your concerns addressed?

Thanks

Ciao

L.


> On 7 Jun 2024, at 01:53, Dino Farinacci <[e-mail]> wrote:
> 
>> Reviewer: Ines Robles
>> Review result: Not Ready
>> 
>> Reviewer: Ines Robles
>> Date: 01-06-2024
>> Version reviewed:draft-ietf-lisp-geo-06
> 
> Thanks for your comments. I have posted -07. See my responses to your comments below.
> 
>> 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.
> 
>> 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.
> 
>> 3- How the geo-coordinates encoding will interoperate with existing LISP
>> deployments, including any backward compatibility issues.
> 
> Added a new section.
> 
>> 4- How to handle errors such as invalid geo-coordinate data or missing fields.
> 
> Fixed in the section 5.
> 
>> 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.
> 
>> 6-  Are the geo-coordinates incorporated in control plane operations?
> 
> Yes. RFC9301 and RFC8060 references make this clear.
> 
>> 7- Perhaps to include some Manageability Considerations?
> 
> For what? All the management of this new type or any type is in RFC9301.
> 
>> 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.
> 
>> 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.
> 
>> 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.
> 
>> Thanks for this document,
> 
> Thanks again for the review,
> Dino
> 
> 
>