Document: draft-ietf-lisp-te Title: LISP Traffic Engineering Reviewer: Mach Chen Review result: Has Nits Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-lisp-te-21 Reviewer: Mach Chen Review Date: 2025-06-03 Intended Status: Experimental Summary: This document is basically ready for publication but has nits that should be considered prior to publication. Comments: The document is easy to read and follow. Major Issues: No major issues found. Minor Issues: No minor issues found. Clarification questions: 1. Regarding ELP mapping entry registration and look up. This document says:"The registration is typically performed by the ETR(s) that are assigned and own the EID-prefix." - Is the mapping database system a centrlized server (e.g., SDN controller) or a function component of each RTR? It seems that it's the former, right? - If so, for a specifc path, there will be at least one corresponding ELP entry registried in the mapping database system; and for a EID-prefix, there may be many ELP entries (e.g., from different source endpoints/ITRs) correlated to it. How does a mapping database system uniquely identify an ELP? When a RTR does an ELP look-up based on the EID-prefix, how does the mapping database system (based on what key information) to determine which entry it should return? - For a specific ELP (e.g., (x,y,etr)), will the returned ELP entry be the same or different when the look-up request is from ITR, x, and Y? Based on my understanding of the current text, it seems that the returned ELP will be different and highly correspond to the RTR that sends the look-up request, right? It's better to add more text to clarify the above questions and make the document clearer. Nits: 1. It's better to expand the terms (e.g., ITR, ETR, etc.) when first use. 2. Section 4, first paragraphy, "...through the locator core...", I did not find the definition of "locator core" in this document or other LISP documents, please clarify and refine the text. 3. Section 4, according to the term definition of seid and seid, they are endpoint identifiers, but in the figure 1/2 and the context, they should be endpoints (e.g., Source Endpoint or Destination Endpoint). Therefore, is it better to use "Source/Destination Endpoint" rather than "seid/'deid"? 4. Section 4, "---> :The physical underlay topology supported by routing protocols.” Is the “--->” a one-hop physical link, or a topology consisting of multiple nodes and links, or something else? 5. Section 4, "In Figure 1 below, the encapsulation tunnel path between ITR and ETR is realized by underlay routers (A, B, C, D)", is it more acurate to say "...by the underlay routers (ITR, A, B, C, D, ETR)"? 6. Section 5, the bullet 3 and 4, it only covers the case that the RLOC is 'x', how about when the ROLC is x'? Seems that change 'x' to 'x'/x' can fix the issue. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
