Hi Padma, Your proposed resolution looks good to me. Will be happy to recheck when you post an update.
Thanks! Dhruv On Tue, Jul 8, 2025 at 11:12 PM Padma Pillay-Esnault <padma.i...@gmail.com> wrote: > 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 <padma.i...@gmail.com> > 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) >> > _______________________________________________ > OPS-DIR mailing list -- ops-...@ietf.org > To unsubscribe send an email to ops-dir-le...@ietf.org >
_______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
