# OPSDIR LC Review of draft-ietf-lisp-te

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written to improve the operational aspects of the IETF drafts. Comments that are not addressed in the last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last-call comments.

## 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.

- There are various MUST conditions that might lead to packet drop. Are there any logging requirements, or any signaling for failure?

- Any hints for troubleshooting? Verify ELP is being followed.

- Any requirement for the LISP YANG module?

- How to handle multiple mapping systems and ELPs across them?

## 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?

## 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! 

- 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"

- Consider adding a reference to RFC 9522 when talking about TE

 - 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. 

- Section 5, in points 3 and 5, what happens if ELP retrieval fails?  

- 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. 

- 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? 

- Section 7, remove reference to expired draft "I-D.filyurin-lisp-elp-probing" that has not been updated since 2018. 

- Section 10, what does weight in locator-set mean in the case of multicast? 

## Nits

- Expand LISP in the title (and then in the abstract)

- Expand on the first use
    - RLOC
    - ITR
    - ETR
    - EID
    - PETR
    - PITR
    - EID
    - xTR
    - etc

- Add a reference or describe what 'path stretch' is. 

- 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.