Hi Tomo, Thank you for review and support. Please see inline for comments.
> -----Original Message----- > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Tomonori Takeda > Sent: 20 January 2017 13:27 > To: 'rtg-...@ietf.org' <rtg-...@ietf.org> > Cc: 'rtg-...@ietf.org' <rtg-...@ietf.org>; > 'draft-ietf-pce-stateful-sync-optimizations....@ietf.org' > <draft-ietf-pce-stateful-sync-optimizations....@ietf.org>; > 'pce@ietf.org' <pce@ietf.org> > Subject: [Pce] RtgDir review: > draft-ietf-pce-stateful-sync-optimizations-07.txt > > 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). > [Dhruv] The purpose of the text is to force state synchronization if the PCEP session is not re-established between the re-delegation timer. This is mainly for sanity. > 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)? [Dhruv] In the step (b) when LSP#3 state is changed, the LSP State DB Version number will be incremented. This number is incremented for all LSPs, and not just for the LSPs that are not delegated. So in this case, full state synchronization will happen. > > 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. [Dhruv] This was done mainly because PCRpt is a list of state reports of LSP and we do not have a way to encode object/TLV for all LSPs in the PCRpt message. > > 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.) > [Dhruv] Good Catch. I can add text "The PCUpd message MUST include an empty ERO as its intended path and SHOULD NOT include the optional objects for its attributes." Thanks! Dhruv > Nits: > None > > > Thanks, > Tomo > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
