Hi Padma, Thanks for addressing my comments, the proposals look good me!
Best regards, Mach From: Padma Pillay-Esnault <[email protected]> Sent: Tuesday, July 8, 2025 1:51 PM To: Mach Chen <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; Padma Pillay-Esnault <[email protected]>; Dino Farinacci <[email protected]> Subject: Re: draft-ietf-lisp-te-21 ietf last call Rtgdir review Hi Mach Thank you for your thorough review and your suggestions please see below PPE for our responses. Please let us know if these proposals addresses your comments. Thanks Padma (and on behalf of my co-authors) 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. PPE > The mapping database system in LISP is logically centralized but may be implemented in a distributed system. In the traffic engineering (TE) use case described here, an SDN controller typically registers ELP mappings into the mapping system. The controller computes ELPs based on network policy or topology awareness. RTRs do not autonomously generate or register ELPs. We will add text to clarify this in Section 5: "In typical deployments, an SDN controller computes ELPs and registers them into the mapping system on behalf of ETRs. The mapping system may be logically centralized or distributed, depending on the implementation." How does a mapping database system uniquely identify an ELP? PPE> ELPs are associated with source/destination context using LCAF encodings, particularly the Source-Destination LCAF or the TE-LCAF. The mapping lookup includes source information (e.g., source EID or RLOC), allowing the mapping system to return the correct ELP. Will make this change in the document for clarification "When multiple ELPs exist for the same EID-prefix, the mapping system uses additional context—such as source address or policy attributes—embedded in the LCAF to disambiguate and return the appropriate 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? PPE > Yes, the returned ELP may vary depending on the querying ITR and the policies encoded in the mapping database. For example, the controller may provision ELPs that are specific to the ingress node or traffic class. The LCAF structure enables this differentiation. We will clarify this point by adding: "Because ELPs can be provisioned per ingress point, mapping lookups for the same EID-prefix may return different ELPs depending on the source of the request, using Source-Destination LCAF or policy tags." It's better to add more text to clarify the above questions and make the document clearer. PPE > See above if these address your comments. Nits: 1. It's better to expand the terms (e.g., ITR, ETR, etc.) when first use. PPE> OK will do 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. PPE> OK.Will change the text to “through the underlay routing infrastructure” and avoid the undefined term locator core. 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"? PPE> Good point. Will change “seid” and “deid” to “Source Endpoint” and “Destination Endpoint” in Figure 1/2 and surrounding text. 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? PPE>We will revise this to: “The physical underlay topology (i.e., the network of routers and links) that is traversed by encapsulated packets.” This clarifies that it is a multihop path, not a single link. 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)"? PPE> OK. We will revise the sentence to: “…realized 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. PPE> OK. We will revise these bullets to cover both cases: “…If the S-bit is not set in the ELP, then the ITR MAY encapsulate to subsequent xTRs in the ELP list (i.e., RLOC 'x', 'x’', etc.) ...
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
