IETF Last Call Review of draft-ietf-lisp-te-21
review-ietf-lisp-te-21-opsdir-lc-dhody-2025-06-04-00

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