[Last-Call] Re: draft-ietf-lisp-te-21 ietf last call Rtgdir review

[Mach Chen <mach.chen=40huawei.com@xxxxxxxxxxxxxx>]

Hi Padma,

 

Thanks for addressing my comments, the proposals look good me!

 

Best regards,

Mach

 

From: Padma Pillay-Esnault <padma.ietf@xxxxxxxxx>
Sent: Tuesday, July 8, 2025 1:51 PM
To: Mach Chen <mach.chen@xxxxxxxxxx>
Cc: rtg-dir@xxxxxxxx; draft-ietf-lisp-te.all@xxxxxxxx; last-call@xxxxxxxx; lisp@xxxxxxxx; Padma Pillay-Esnault <padma.ietf@xxxxxxxxx>; Dino Farinacci <farinacci@xxxxxxxxx>
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.) ...

 

 

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx