Skip to main content

Last Call Review of draft-ietf-pce-stateful-sync-optimizations-07
review-ietf-pce-stateful-sync-optimizations-07-rtgdir-lc-takeda-2017-01-20-00

Request Review of draft-ietf-pce-stateful-sync-optimizations
Requested revision 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
I-D 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 Fox Franke (diff)
Tsvart Last Call review of -08 by Adrian Farrel (diff)
Assignment Reviewer Tomonori Takeda
State Completed
Request Last Call review on draft-ietf-pce-stateful-sync-optimizations by Routing Area Directorate Assigned
Reviewed revision 07 (document currently at 10)
Result Has issues
Completed 2017-01-20
review-ietf-pce-stateful-sync-optimizations-07-rtgdir-lc-takeda-2017-01-20-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-pce-stateful-sync-optimizations-07.txt
 Reviewer: Tomonori Takeda
 Review Date: Jan 20th, 2017
 IETF LC End Date: Not known
 Intended Status: Standards Track

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

Comments:
 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:
 None

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

 Suppose
   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.)

Nits:
 None

Thanks,
Tomo