[RTG-DIR] FW: RtgDir Early Review: draft-ietf-pce-gmpls-pcep-extensions

[David Sinicrope <[e-mail]>]

FYI

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


Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions

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 ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>

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

Summary:

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

Comments:
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 too.

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 elaborate.

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.

Nits:
Miscellaneous warnings:
  ----------------------------------------------------------------------------

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

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


From: DEBORAH BRUNGARD <[e-mail]>
Date: Monday, October 15, 2018 at 12:07 PM
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, David Sinicrope <[e-mail]>
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 comments.

Thanks!
Deborah