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> T*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]
