Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions
draft-ietf-teas-te-express-path-05

As mentioned by Sue in her OPS-DIR review:
Status: Review with nits (very minor nits)  

General comments:  Document is precise, well-written, and understandable to those who have read the documents this draft depends on.  There is not a specific operations section, but this mechanisms would be included in a PCE or other calculation engine.   This reviewer does not see any reason why additional text needs to be utilized.  Individuals who write such algorithms and programs are utilizing these mechanisms to provide better paths.

Nit #1:  section 1.2

EF and AF abbreviations are not spelled out.  Unless these are part of the RFC editor’s abbreviations, it should be spelled out.

Nit #2: section 2.3.1

/Link Los sub-TLV/Link Loss sub-TLV/

/Sub-TLV[I-D-ietf.isis-te-metric-extensions]/sub-TLV [I-D-ietf.isis-te-metric-extensions] 


I would add: spell out the ERO abbreviation.

Robert Spark's Gen-ART review comment should be taken into account:

This document is all about considerations. Specifically, it discusses what to consider if you were to build a path computation function that uses the kind of information you get from the TE metric extensions in RFC7471 and draft-ietf-isis-te-metric-extensions. It does not appear to be requirements for standardization work - rather, it is information for operators to use when building functions that don't necessarily need standardization.

However, it looks as if the document may have once contemplated actually specifying a path computation function, and has legacy text from that thought?

The abstract says "This specification uses network performance data ... to perform such path selections." But this document doesn't perform such path selections (or specify how to do them).

Section 1.1 says "The following are the requirements that motivate this solution." But this draft doesn't actually specify a "solution". It discusses what to consider if you were to build a path computation function. Could this be framed as a set of goals to keep in mind while building your own such function?

The third paragraph of section 1.2 could use clarification. I suspect the word "even" in the 4th sentence should be removed, and the judgement in "There may be legitimate use" is out of place. Consider rewriting the paragraph using simpler sentences.

Section 2.3 appears to be considerations specifically for interpreting the anomalous bit in one specific extension? If so, the introduction to the section should call that out. If not, the section's structure needs improvement. The section also calls out two questions, but only discusses one of them explicitly.

I'll follow Stephen's comments, especially on the DoS question.

- The shepherd write up says no IPR declarations, but the tracker
disagrees. Did the WG consider the (in this case fairly innocuous)
IPR declaration? [1]

   [1] https://datatracker.ietf.org/ipr/2200/

- Are there unexpanded acronyms here? Be worth a pass to check.

- section 1: "plagued prior attempts" screams out that it needs a
reference or two.

- section 4: I'm surprised there is no mention of the possible
impact of (D)DoS on this. Couldn't that affect path selection based
on metrics? If so, shouldn't you say how?