Skip to main content

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

Request Review of draft-ietf-ospf-te-link-attr-reuse
Requested revision 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
I-D last updated 2020-05-29
Completed reviews Tsvart Last Call review of -12 by Michael Scharf (diff)
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)
Opsdir Last Call review of -12 by Scott O. Bradner (diff)
Genart Telechat review of -14 by Linda Dunbar (diff)
Opsdir Telechat review of -14 by Scott O. Bradner (diff)
Assignment Reviewer Daniele Ceccarelli
State Completed
Request Last Call review on draft-ietf-ospf-te-link-attr-reuse by Routing Area Directorate Assigned
Posted at
Reviewed revision 12 (document currently at 16)
Result Has nits
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]