Last Call Review of draft-ietf-isis-te-metric-extensions-07
review-ietf-isis-te-metric-extensions-07-genart-lc-holmberg-2015-12-30-00

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document:                                                 
draft-ietf-isis-te-metric-extensions-07.txt

Reviewer:                                                   Christer Holmberg

Review Date:                                               19 January 2016

IETF LC End Date:                                          30 December 2015

IETF Telechat Date:                                       21 January 2016

Summary:           The document is well written, and is almost ready for
publication. However, there are some editorial issues that I ask the authors to
address.

Major Issues: None

Minor Issues: None

Editorial Issues:



GENERAL:

--------------



Q_GEN_1:



In section 1, you say that the extension is

hereafter called "IS-IS TE Metric Extensions".



However, you then refer to it as e.g. "TE Metric Extensions" and "ISIS TE
Metric Extensions".



Please use consistent terminology.





Q_GEN_2:



Sometimes the text says “sub-TLV”, sometimes “SubTLV”, and sometimes “Sub TLV”.
Please use consistent terminology.





SECTION 1:

--------------



Q_1_1:



I suggest to rewrite:



“This document describes extensions to IS-IS Extended Reachability TLV

defined in [RFC5305] (hereafter called "IS-IS TE Metric Extensions"),…”



…to:



“This document describes extensions (hereafter called "IS-IS TE Metric
Extensions")

to IS-IS Extended Reachability TLV defined in [RFC5305],…”



… to make it more clear that "IS-IS TE Metric Extensions" refers to the
extensions, and not to the TLV.





SECTION 2:

--------------



Q_2_1:



I have some difficulties to follow the A,B,C bullet list logic.



I think it would be more clear to structure it e.g. like:



“From an  MPLS perspective, the intent of the A bit is to permit LSP ingress

nodes to determine whether the link referenced in the sub-TLV affects any

of the LSPs for which it is ingress.



If any of the LSPs are affected, the receiving node shall determine whether

those LSPs still meet end-to-end performance objectives. If the objectives

are not met the receiving node could conceivably move affected traffic to a pre-

established protection LSP or establish a new LSP and place the traffic in it.”