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."
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."
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?
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:
It's better to add more text to clarify the above questions and make the"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."
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.
and avoid the undefined term locator core.
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"?
topology supported by routing protocols.” Is the “--->” a one-hop physical
link, or a topology consisting of multiple nodes and links, or something else?
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)…”
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
