Last Call Review of draft-ietf-pce-stateful-sync-optimizations-07

Request Review of draft-ietf-pce-stateful-sync-optimizations
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-01-20
Requested 2017-01-03
Requested by Xian Zhang
Authors Edward Crabbe, Ina Minei, Jan Medved, Robert Varga, Xian Zhang, Dhruv Dhody
Draft last updated 2017-01-20
Completed reviews Rtgdir Last Call review of -07 by Tomonori Takeda (diff)
Genart Last Call review of -09 by Christer Holmberg (diff)
Secdir Last Call review of -09 by Daniel Franke (diff)
Tsvart Last Call review of -08 by Adrian Farrel (diff)
Assignment Reviewer Tomonori Takeda 
State Completed
Review review-ietf-pce-stateful-sync-optimizations-07-rtgdir-lc-takeda-2017-01-20
Reviewed rev. 07 (document currently at 10)
Review result Has Issues
Review completed: 2017-01-20



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-pce-stateful-sync-optimizations-07.txt
 Reviewer: Tomonori Takeda
 Review Date: Jan 20th, 2017
 IETF LC End Date: Not known 
 Intended Status: Standards Track

 I have some minor concerns about this document that I think should be resolved before publication.

 This document defines PCEP extensions for optimizing state synchronization.
 Base state synchronization is defined in [I-D.ietf-pce-stateful-pce].

 The document is well organized and easy to read.
 I have some technical questions.

Major Issues:

Minor Issues:
 1) I have a question on incrementing rules for LSP State Database Version Number.
 In page5, it says:
   If state synchronization avoidance is enabled, a PCC MUST increment
   its LSP State Database Version Number when the 'Redelegation Timeout
   Interval' timer expires (see [I-D.ietf-pce-stateful-pce]) for the use
   of the Redelegation Timeout Interval).

 Can we ensure that PCC's LSP state DB does not change if LSP State Database Version Number does not change?

 For example, suppose a PCC contains three LSPs.
  LSP#1: delegated to PCE#1
  LSP#2: delegated to PCE#1
  LSP#3: not delegated

   a) PCEP session between PCE#1 and PCC is terminated.
   b) LSP#3 state changed.
   c) PCEP session between PCE#1 and PCC is reestablished (within  'Redelegation Timeout Interval').
 In this case, I think LSP State Database Version Number does not change, but LDP state DB changed in b).
 Are you assuming that PCRpt for b) is stored and sent to PCE#1 after c)?
2) Is there any reason why LSP State Database Version Number is encoded per LSP object (LSP-DB-VERSION TLV of LSP object), not per PCRpt?
I think LSP state DB is per PCC, not per LSP. Thus it sounds more straight-forward to encode ID (LSP State Database Version Number) per PCRpt.

3) In page16 (Section 5.2.). it says:

   If the LSP-DB Version is mis-matched, it can send a PCUpd message with PLSP-
   ID = 0 and SYNC = 1 in order to trigger the LSP-DB synchronization process.

 For completeness, it would be good to clarify how to treat any parameter updates for the LSP in PCUpd.
 (Note that Section 6.2 says such procedures for PCE-triggered State Re-synchronization.)