Last Call Review of draft-ietf-ospf-te-link-attr-reuse-07
review-ietf-ospf-te-link-attr-reuse-07-rtgdir-lc-ceccarelli-2019-09-18-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see 
<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-ospf-te-link-attr-reuse-08.txt
Reviewer: Daniele Ceccarelli
Review Date: 2019-09-13
IETF LC End Date: date-if-known
Intended Status: Standard Track

Summary:
I have significant concerns about this document and recommend that the Routing
ADs discuss these issues further with the authors.

Comments:

The drafts needs some improvement to be clear and easy to read. It is outside
the scope of the RTG-Directorate review to consider consensus on it, but the it
is not possible to ignore comments received from a WG member of its usefulness.
Implementations on ISIS segment routing and OSPF segment routing (publicly
available) prove that applications like Flexible Algorithm, TI-LFA and R-LFA
can be implemented using TE parameters compliant with RFC3630 and RFC5305
without the need for these extensions.

That said the rest of the review will be limited only to the quality of the
document.

Major Issues:

*       No major issue in addition to the one described in the comments.

Minor Issues:

*       Abstract: it would be nice to have an overview of what is the purpose
of distributing the attributes (in addition to MPLS-TE and GMPLS). The document
starts with a very generic scope but then focuses on segment routing. It could
be stated at the beginning. *       Section 2: what does this sentence mean?:
“Additionally, there will be additional standardization effort. Additionally,
there will be additional standardization effort.  However, this could also be
viewed as an advantage as the non-TE use cases for the TE link attributes are
documented and validated by the LSR working group” *       It is not clear the
usage of RFC2119 language (RECOMMENDED) in section 2.1, is section 2.1 defining
a new procedure? My understanding is that section 2 is the actual solution
while section 3 is the newly defined one. Am I wrong? If so it should be made a
bit more clear and I would expect to see RFC2119 language only in section 3. * 
     Section 3: “This situation SHOULD be logged as an error” how? Should a
notification be sent? Logging an error is not part of the protocol definition
but rather an implementation issue. *       Section 4: the title is misleading.
It is defining how to encode the list of attributed defined at the end of
section 3 (some of them are reused, some others are TBD), why the title of the
section is Reused TE link attributes? *       Sections 5-6-7: Section 3
describes the procedure and TLV format, section 4 the encoding of the
attributes…what is defined in section 5-6-7. If I search for e.g. Maximum link
bandwidth (the title of section 5), the first occurrence is the title of
section 5. Maybe gouping sections 5-6-7 into a single one with an intro of what
is defined could improve the reading.

Nits:

*       MPLS TE is sometimes in capital letters and sometimes not.
*       SRTE expand on first use.

BR

Daniele