Re: [RTG-DIR] Routing directorate review of draft-ietf-teas-scheduled-resources-04

["Adrian Farrel" <[e-mail]>]

Jon,
 
Thanks. These all look like reasonable points for discussion or immediate change.
 
I'll get on it SOON.
 
Ciao,
Adrian
 
From: rtg-dir [mailto:[e-mail]] On Behalf Of Jonathan Hardwick
Sent: 15 January 2018 14:14
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; TEAS WG ([e-mail])
Subject: [RTG-DIR] Routing directorate review of draft-ietf-teas-scheduled-resources-04
 
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