Please use this email to respond - added a few fixes to the text Thanks Padma
On Tue, Jul 8, 2025 at 10:38 AM Padma Pillay-Esnault <[email protected]> wrote: > > Hi Dhruv > > Thank you for your thorough review and helpful comments. We appreciate > your feedback on improving the operational aspects of the draft. Please see > PPE for our responses below > > ## Manageability or Operational Considerations > > The document lacks a dedicated section for Manageability or Operational > Considerations. Authors should consider if adding such a section could help > (see RFC 5706). Some high-level thoughts - > - Are there any operational considerations in how an administratively > specified > path is set? The I-D simply states that the typical ELP is registered by > ETR or > SDN, but does not provide any operational considerations on how the ELP is > determined, configured, or monitored. > > > *PPE> Agreed. In the next revision, we will add a section titled > Manageability Considerations, following the guidance of RFC 5706. This > section will include: The typical ELP is based on the operational > objectives of the operator such as traversing or avoiding some hops based > on the resource management. As configuration is based on the overall > topology and network operator objectives, we believe the figures in the > draft suffice to illustrate representative scenarios. We can add a > clarification that ELPs are typically configured via SDN controllers or > manually by network administrators.Regarding monitoring - we will reuse the > underlying LISP protocol usual monitors to troubleshoot - iow we are not > adding specific tools to monitor the path of traffic.* > > > - There are various MUST conditions that might lead to packet drop. Are > there > any logging requirements, or any signaling for failure? > > *PPE> OK. We will clarify that while logging on the dataplane is generally > discouraged, some validation can be done at the time of registration. Since > Map-Servers do not validate the contents of ELPs, operators are responsible > for ensuring correctness.* > > - Any hints for troubleshooting? Verify ELP is being followed. > - Any requirement for the LISP YANG module? > > *PPE> We will state that this feature does not depend on the LISP YANG > model. However, the ongoing LISP YANG effort includes support for fault and > policy reporting. In this draft, we specified "ELP-probing" which was a > hop-by-hop (encapsulated hop) RLOC-probing per RFC9301 but also across the > entire ELP (meaning each RLOC-probe hop metrics were summed up to give you > metrics on the entire ELP). We will add the following text *"ELP-Probing > is a supported technique (built on hop-by-hop RLOC-Probing per RFC 9301) to > troubleshoot path-level behavior." > > - How to handle multiple mapping systems and ELPs across them? > > *PPE> We will add a note that ELPs are scoped to a single mapping system, > and if multiple systems are used, consistency must be ensured > administratively.* > > ## Publication Track > > I understand that the working group has a history of publishing documents > under > the “Experimental” track. However, I also note that the core LISP > specifications have recently been moved to the “Standards Track.” The > shepherd > write-up states that the Experimental stream is appropriate for this > document > as it describes a new feature. That raises the question: should the WG > continue > to publish all new features as Experimental? > > More importantly, the abstract claims there are no new protocol changes; in > that case, can this be Informational? > > *PPE > Thanks and this has come up in a couple of the reviews of other > LISP drafts as well and we propose to add a similar text for clarification > for this draft: "This document is part of a development effort to include > Traffic engineering in LISP. It is not part of an "experiment", as not all > experimental RFCs are necessarily part of an experiment. It is rather about > the maturity level of the technology."* > ## Minor > > - The abstract says, "The mechanisms described in this document require no > LISP > protocol changes but do introduce a new locator (RLOC) encoding"; I could > not > find any new encoding changes! > > *PPE> Thank you for catching this inconsistency. The reference to a new > RLOC encoding is about the new operational behavior and rloc encoding style > as per the comment above. Will fix the abstract.* > > - Introduction should be the first section as per > https://datatracker.ietf.org/doc/html/rfc7322#section-4.8.1; I suggest > making > the "Requirements Language" a subsection of the "Introduction" > > *PPE> Agreed. We will move the "Requirements Language" into a subsection > within the "Introduction" to align with RFC 7322 as you pointed out* > > - Consider adding a reference to RFC 9522 when talking about TE > > *PPE>Good suggestion. We will include a reference to RFC 9522 where we > introduce the concept of traffic engineering in the context of LISP in the > intro* > > - Section 3, this text - > > ```` > Explicit Locator Path (ELP): The ELP is an explicit list of RLOCs > for each RTR a packet SHOULD travel along its path toward a final > destination ETR (or PETR). The list MAY be a strict ordering > where each RLOC in the list is visited. > ```` > > v/s the text in section 5 > > ```` > 2. The ITR will encapsulate the packet to RLOC 'x'. If the S-bit is > not set in the ELP, then the ITR MAY encapsulate to subsequent > xTRs in the ELP list. Otherwise, when the S-bit is set and an > xTR determines the RLOC is not reachable, it MUST NOT use any of > the remaining entries in the ELP list and drop the packet. If > the L-bit is set, then the ITR does a mapping system lookup on > EID 'x' to obtain an RLOC, call it x', which it then encapsulates > to. > ```` > > Section 3 is technically correct, but the framing in Section 5 is more > useful. > Perhaps avoid using SHOULD and MAY in section 3 and just describe how it > works > based on the setting of the S-bit per RLOC instead of for the full path. > > *PPE > To address your comment .. how about “An ELP is an explicit list of > RLOCs indicating intermediate RTRs that a packet is intended to traverse en > route to its destination. The list can define a strict order when each RLOC > must be visited in sequence.”* > > - Section 5, in points 3 and 5, what happens if ELP retrieval fails? > > *PPE> We will clarify that if ELP retrieval fails (e.g., the mapping > system does not return an ELP), the ITR follows the fallback behavior > defined in the base LISP specification (RFC 9301), typically performing > encapsulation using standard RLOCs from the mapping entry. This behavior > will be explicitly stated in Section 5.* > > - Section 5.3, CoS in TE has a different meaning than just > source/destination > pairs. I suggest you rename the section and avoid the term CoS. > > *PPE> Agreed. Will rename "Policy-Based Path Selection" , and reword it > to eliminate CoS* > > *-* Section 5.4, In "An ELP that is first used by an ITR MUST be > inspected for > encoding loops. If any RLOC appears twice in the ELP, it MUST NOT be > used.", > what does 'it' refer to? ELP or the RLOC that appears twice? > > *PPE> How about this change for clarification: “An ELP that is first used > by an ITR MUST be inspected for encoding loops. If any RLOC appears more > than once in the ELP, the ELP MUST NOT be used.”* > > - Section 7, remove reference to expired draft > "I-D.filyurin-lisp-elp-probing" > that has not been updated since 2018. > > *PPE> This ELP draft that you could traceroute through it and see if a > reply came back using the RLOC-probing. This draft can be revived if there > is an interest. We left it there for info. * > > - Section 10, what does weight in locator-set mean in the case of > multicast? > > *PPE > We will clarify that LISP multicast forwarding uses the full > locator set rather than a weighted selection among locators. As such, the > weight parameter has no operational meaning in multicast scenarios and > should be ignored. This is consistent with the **Draft‑ietf‑lisp‑rfc6831bis > (LISP for Multicast Environments) which will update RFC6831.* > > ## Nits > > - Expand LISP in the title (and then in the abstract) > > *PPE > We have many drafts that use the acronym of the protocol in the > title and wish to keep it as is. We will expand in the abstract.* > > > - Expand on the first use > - RLOC > - ITR > - ETR > - EID > - PETR > - PITR > - EID > - xTR > - etc > > *PPE> OK * > > - Add a reference or describe what 'path stretch' is. > > *PPE> Agree. We will define path stretch in simple terms or add a > reference to clarify that it refers to the ratio of the length of the > actual path used to the shortest possible path.* > > - Section 5, in the text "The notation for a general formatted ELP is (x, > y, > etr)", I suggest changing it to (x, y, ... etr) to explicitly allow more > hops. > > *PPE> Agree and thanks for the suggestion. Will revise the text.* > > Thanks again for your insightful comments > Padma (and on behalf of the co-authors) >
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
