Last Call Review of draft-ietf-ospf-te-link-attr-reuse-12

Request Review of draft-ietf-ospf-te-link-attr-reuse
Requested rev. no specific revision (document currently at 16)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2020-05-29
Requested 2020-05-14
Requested by Alvaro Retana
Authors Peter Psenak, Les Ginsberg, Wim Henderickx, Jeff Tantsura, John Drake
Draft last updated 2020-05-29
Completed reviews Rtgdir Last Call review of -07 by Daniele Ceccarelli (diff)
Rtgdir Last Call review of -12 by Daniele Ceccarelli (diff)
Genart Last Call review of -12 by Linda Dunbar (diff)
Tsvart Last Call review of -12 by Michael Scharf (diff)
Opsdir Last Call review of -12 by Scott Bradner (diff)
Genart Telechat review of -14 by Linda Dunbar (diff)
Opsdir Telechat review of -14 by Scott Bradner (diff)
Assignment Reviewer Daniele Ceccarelli
State Completed
Review review-ietf-ospf-te-link-attr-reuse-12-rtgdir-lc-ceccarelli-2020-05-29
Posted at
Reviewed rev. 12 (document currently at 16)
Review result Has Nits
Review completed: 2020-05-29



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 ‚Äč

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-12
Reviewer: Daniele Ceccarelli
Review Date: 2020-05-29
IETF LC End Date: date-if-known
Intended Status: Standard Track


The readibility of the draft has been significantly improved since my last review (v07), mostly the abstract and the introduction, which now cleary state what is the scope of the draft. I also appreciated the introduction of section 3 where a description of the existing solution is described. 

Minor issues: 
- Section 4.1 - Advantages with respect to RSVP-TE are described while the text speaks about advantages with respect to RSVP-TE and GMPLS, probably it could be changed into: advantages with respect to RSVP-TE when used in packet networks and in GMPLS, something like this.
- Section 5 - Why for the UDABM it doens't say the value MUST be 0,4,8 but rather says "the legal values are" ? Is 8 octets future-proof enough? or conversely, if only 3 values are defined why do we need 8 octects as option?
- Section 8 - I really find it hard to understand this small section. 

-  Unidirectional Link Dela [RFC7471]