Skip to main content

Last Call Review of draft-ietf-pce-gmpls-pcep-extensions-12

Request Review of draft-ietf-pce-gmpls-pcep-extensions
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2018-11-02
Requested 2018-10-05
Requested by Deborah Brungard
Authors Cyril Margaria , Oscar Gonzalez de Dios , Fatai Zhang
I-D last updated 2018-11-18
Completed reviews Rtgdir Last Call review of -12 by Dave Sinicrope (diff)
Opsdir Last Call review of -12 by Tianran Zhou (diff)
Secdir Last Call review of -12 by Vincent Roca (diff)
Secdir Telechat review of -13 by Vincent Roca (diff)
Genart Telechat review of -14 by Elwyn B. Davies (diff)
Prep for Last Call
Assignment Reviewer Dave Sinicrope
State Completed
Request Last Call review on draft-ietf-pce-gmpls-pcep-extensions by Routing Area Directorate Assigned
Reviewed revision 12 (document currently at 16)
Result Has nits
Completed 2018-11-18

From: David Sinicrope <>
Date: Sunday, November 18, 2018 at 8:48 AM
To: "" <>,
<>, "Yemin (Amy)" <>, Jonathan Hardwick
<>, "" <> Subject:
RtgDir Early Review: draft-ietf-pce-gmpls-pcep-extensions


I have been selected to do a routing directorate “early” review of this draft.

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

As this document is in working group last call, my focus for the review was to
determine whether the document is ready to be published. Please consider my
comments along with the other working group last call comments.

For more information about the Routing Directorate, please see

Document: draft-ietf-pce-gmpls-pcep-extensions-12.txt
Reviewer: David Sinicrope
Review Date: November 17, 2018
Intended Status: Standards Track


  *   This document is basically ready for publication, but has nits and
  clarifications that should be considered prior to being submitted to the IESG.

Although a bit terse on motivation the document is of good quality and detail
providing the level of information needed for protocol specification and
implementation. The comments provided below are aimed at improving readability,
comprehension and consumption of the document by those that would use it for
architecture, solution design and implementation.

Abstract.  Please provide some detail scope and purpose beyond one line.  This
is supposed to answer why / whether I should delve into the document.

General Comments (no particular section)
1. Given that this document is providing the detail for the requirements in
7025, it might be advantageous to the reader to structure the document
according to the requirements listed in 7025.

2. The document gives a sparse highlight of what extensions are needed and why
Section 1 and then launches into the details in section2 and on.  More
elaboration on motivation and gaps and requirements would be helpful to better
understand why the extensions are needed.

3. This should be liaised to ITUT SG15 Q12 and Q14 for review.  Maybe Q11/15

Sec 1.2 - RFC 7025 has 13 different requirements listed.

1. Why are they repeated here and not simply referenced? One must have both
documents to fully understand the requirements this document is addressing, so
there is no need to restate (and possibly misstate) the agreed requirements
here for readability

2. Why is this only a subset of the requirements in RFC 7025?  Is there less
covered here than in RFC7025?  If so this must be spelled out in terms of
coverage.  Perhaps a table to explain the functions noted in 7025 vs what this
document covers.

Introduction - this document assumes a significant familiarity with rfc7025 and
the other documents listed.  It should state this outright.

Sec 1.3 - please correlate these to the requirements they are addressing.  Also
please provide more explanation.  Some of these are seemingly contradictory the
way they are listed currently. E.g. END-POINTS and ERO make it sound confused
as to whether the 7025 requirement on unnumbered interfaces is addressed  or
not. Some examples would go a long way to providing clarity Note: I noted this
is done later in the specific extensions, but could also be done here.

Sec 1.3 - PCEP objects, needs plural

Sec 1.3 - they can’t be shortcomings if they were not designed for the use
noted.  Perhaps “gaps in functional coverage” or “areas for enhancement” is a
better description.

Sec 1.3 - why is the infusion/exclusion of labels a shortcoming?  Please

Sec 1.3 – Protection should be listed with the others “shortcomings” right now
looks like a summary which it isn’t.  Indent this text.

Sec 1.3 covered pcep extensions - covered by what? This document?  If so,
please say so. Also say/elaborate on why they are needed.  Note: I can see this
is done much more in the individual sections describing the extension.  It
would suffice then to add a note here that more detail on motivation is
provided with each individual extension.

Sec 2.2 - excellent cross reference to RFC 7025. I see this is done elsewhere. 
This makes addressing solution architecture most helpful.

Miscellaneous warnings:

  == Line 1206 has weird spacing: '...ted bit  routi...'

  -- The document date (September 27, 2018) is 52 days in the past.  Is this

Date: Monday, October 15, 2018 at 12:07 PM
To: ""
<> Cc: ""
<>, David Sinicrope <> Subject:
IETF Last Call started-draft-ietf-pce-gmpls-pcep-extensions

Hi Authors (and Shepherd),

I thought your document was well written and considering how long we have been
waiting for this document😊, I have started IETF Last Call. I’ve started the
IETF Last Call due to the window closing in on the next IETF meeting when the
other Areas prefer not to have Last Calls overlapping. Dave Sinicrope will be
the rtg-dir reviewer and will do his review in parallel with Last Call.

Please be sure to have one of you available as the main pen holder to be
responsive to Dave, other Area Directorate reviewers comments, and IESG