Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions
draft-ietf-teas-te-express-path-05
Yes
(Deborah Brungard)
No Objection
(Alvaro Retana)
(Barry Leiba)
(Ben Campbell)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)
Recuse
(Alia Atlas)
Note: This ballot was opened for revision 03 and is now closed.
Deborah Brungard Former IESG member
Yes
Yes
(for -03)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -03)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -03)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(for -03)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2015-10-01 for -03)
Unknown
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.
Jari Arkko Former IESG member
No Objection
No Objection
(2015-10-01 for -03)
Unknown
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.
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -03)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-09-30 for -03)
Unknown
I'll follow Stephen's comments, especially on the DoS question.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -03)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -03)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-09-30 for -03)
Unknown
- 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?
Terry Manderson Former IESG member
No Objection
No Objection
(for -03)
Unknown
Alia Atlas Former IESG member
Recuse
Recuse
(for -03)
Unknown