Last Call Review of draft-ietf-teas-scheduled-resources-04
review-ietf-teas-scheduled-resources-04-rtgdir-lc-hardwick-2018-01-15-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

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-teas-scheduled-resources-04.txt
Reviewer: Jon Hardwick
Review Date: 15 January 2018
IETF LC End Date: TBD
Intended Status: Informational

Summary
This document is basically ready for publication.  I have flagged a few
clarifications and editorial changes that I think should be made. I think this
document is very well put together.  It does an excellent job of describing the
problem space and solution framework for scheduled resource reservations in a
TE network.  I agreed with its conclusions.

Section 2.5

I found the following sentence to be misplaced, because it is the first
sentence in this section that talks about LSP reservation requests, and it
appears in the middle of a paragraph that is discussing scheduling state.

Multiple periods, possibly
   of different lengths, may be associated with one reservation request,
   and a reservation might repeat on a regular cycle.
LSP reservation requests are then not mentioned again until the final
paragraph, where it says that you must keep them in a database, too.

Please explain and differentiate more clearly between the database of scheduled
resources and the database of LSP reservation requests.  You should say what
information is contained in each, and how the information in the latter relates
to the information in the former.  I suggest you delete the above quoted
sentence and then expand the final paragraph to give more details on the LSP
reservation request database.

Actually, now I have read further, section 3.2 already does this very well, so
I think it would be best to combine 2.5 with it.

Section 3.1

In the discussion of the issues of centralizing the scheduling state database,
the third bullet appears not to be an issue, but a mitigation of bullet 2.  I
think it should be merged into bullet 2.

In the final bullet, you say that the central server must have full control of
reservations, but I think you should take the extra step and justify this
statement.  If a node sets up its own RSVP-TE LSP without contacting the
server, then it may invalidate some plans that the server has already made. 
The server will eventually find out about the new reservation, but (a) it might
take too long to find out and (b) the server will have no idea how long the
reservation is going to persist for.  I think you are saying that, for reasons
(a) and (b), all reservations must be scheduled by the server without
exception.  Correct?

Section 3.2

This treads much of the same ground as section 2.5 and does it much better.  I
suggest merging the two, or making 2.5 very brief and giving a forward
reference to 3.2.

Section 4.1

I think it would be useful to note in paragraph 2 that the update to the TEDB
may trigger a re-optimization of the TEDB, potentially changing a previously
computed reservation for existing LSP requests, either by pre-empting them or
by moving their planned paths.  And this might involve some sort of update sent
back over interface (a).

Similarly, in the final paragraph, if an LSP request is cancelled then it may
trigger a re-optimization of the TEDB such that previously requested LSPs are
re-planned or become viable.

References
Please update:
draft-ietf-pce-pceps -> RFC 8253
draft-ietf-pce-stateful-pce -> RFC 8231