Skip to main content

IETF Last Call Review of draft-ietf-lisp-te-21
review-ietf-lisp-te-21-rtgdir-lc-chen-2025-06-03-00

Request Review of draft-ietf-lisp-te
Requested revision No specific revision (document currently at 21)
Type IETF Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2025-06-04
Requested 2025-05-14
Requested by Jim Guichard
Authors Dino Farinacci , Michael Kowal , Parantap Lahiri , Padma Pillay-Esnault
I-D last updated 2025-07-10 (Latest revision 2025-05-13)
Completed reviews Genart IETF Last Call review of -21 by Peter E. Yee
Rtgdir IETF Last Call review of -21 by Mach Chen
Opsdir IETF Last Call review of -21 by Dhruv Dhody
Assignment Reviewer Mach Chen
State Completed
Request IETF Last Call review on draft-ietf-lisp-te by Routing Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/WsmE6JHEYNXMhTWdp3sNMd9E7MQ
Reviewed revision 21
Result Has nits
Completed 2025-06-03
review-ietf-lisp-te-21-rtgdir-lc-chen-2025-06-03-00
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.