Hi Xian Thanks for your replies. Here are my suggestions.
- The draft should explain more clearly the circumstances in which this is a worthwhile optimization. - I agree that there is no need for you to go into detail about how the PCC's cache of database updates should operate. However, I do think that you should state that it is not necessary for the PCC to store a complete history of all database updates. - You should define a mechanism where the PCC can choose to send a full resynchronization instead of an incremental synchronization. This could be either because of a policy on the PCC or because the PCC does not have enough history in its database update cache to perform an incremental synchronization. Regards Jon -----Original Message----- From: Zhangxian (Xian) [mailto:zhang.x...@huawei.com] Sent: 09 July 2013 14:17 To: Jonathan Hardwick Cc: pce@ietf.org; draft-zhx-pce-stateful-lsp-s...@tools.ietf.org Subject: Re: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt Hi, Dear Jon, Thank you very much for the useful comments. Please see our reply inline (looking for [AUTHORS]): ________________________________________ 发件人: Jonathan Hardwick [jonathan.hardw...@metaswitch.com] 发送时间: 2013年7月9日 5:46 到: Zhangxian (Xian); draft-zhx-pce-stateful-lsp-s...@tools.ietf.org Cc: pce@ietf.org 主题: RE: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt Hi there The incremental state synchronization mechanism looks like a potentially useful optimization. I have a few questions for the draft authors. The motivation of the incremental synchronization mechanism is to reduce the time and bandwidth of the synchronization process. This is likely to be true in scenarios where the LSP database is large and the number of changes since the last successful synchronization is small. Conversely, if the LSP database is small and the PCE has taken a long time to recover then it might actually be quicker to perform a full mark-and-sweep synchronization. [AUTHORS]: Agreed. Is the intent of your draft that the PCC and PCE can choose whether to perform an incremental or full synchronization based on how out of date the PCE's database is? In which case, who makes the choice, using what criteria, and how is that choice made known to the other party? Or is the intent that incremental synchronization is always preferred if both parties support it? [AUTHORS]: In the current version 'incremental synchronization' is always preferred if both parties support it. Do you feel strongly if this needs changing? The incremental synchronization relies on the PCC replaying the necessary PCRpt messages to the PCE to bring it up to date, including any that relate to deleted LSPs. Do you have any guidelines on how many PCRpts the PCC should cache and for how long? Have you considered a check-pointing mechanism where the PCE occasionally confirms that is has a persistent copy of DB version x to avoid this cache from growing too large? [AUTHORS]: PCC needs to cache PCRpts of deleted LSPs only if there exist some PCEP session to a stateful PCE a)which was previously up and LSP-DB synchronized, but temporarily down; b)supported LSP-DB-Version TLV in PCRpts (IDB flag was set in OPEN). [AUTHORS]: Also, say the DB version when a LSP gets deleted is X, The DB version at the time of last synchronization for a 'down' session be DBV(i) where i=1 to N (N temporarily down sessions with above conditions satisfied), Then you no longer need to cache PCRpts of a deleted LSPs if X < MIN{DBV(i),(i=1...N)} [AUTHORS]: Whenever a down session comes up and state is synchronized, the above condition can be used to clear the cache. Since this is a local mechanism of PCC, should it be a part of the specification? You need to deal with the case where both PCE and PCC set the D flag and yet the PCC's cache of PCRpts does not go back far enough to make an incremental synchronization possible. In this case, a full synchronization is necessary regardless of the D bits. [AUTHORS]: One way to do this would be to have another flag in LSP object along with SYNC to indicate if PCC report is for incremental state synchronization. Best Regards, Xian (on behalf of all authors) Regards Jon -----Original Message----- From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Zhangxian (Xian) Sent: 08 July 2013 10:59 To: pce@ietf.org Subject: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt Hi, Dear PCErs, We have just upload a new draft specifying the need in PCEP to allow incremental LSP state synchronization as well as PCE control over this process for stateful PCE(s). It also proposes PCEP extensions to support the requirements. Any comments/feedback are appreciated. Regards, Xian ( on behalf of all authors) ________________________________________ 发件人: internet-dra...@ietf.org [internet-dra...@ietf.org] 发送时间: 2013年7月7日 19:41 到: Zhangxian (Xian); Xiegang (A); Dhruv Dhody 主题: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt A new version of I-D, draft-zhx-pce-stateful-lsp-sync-00.txt has been successfully submitted by Xian Zhang and posted to the IETF repository. Filename: draft-zhx-pce-stateful-lsp-sync Revision: 00 Title: LSP Synchronization for Stateful Path Computation Element (PCE) Creation date: 2013-07-05 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-zhx-pce-stateful-lsp-sync-00.txt Status: http://datatracker.ietf.org/doc/draft-zhx-pce-stateful-lsp-sync Htmlized: http://tools.ietf.org/html/draft-zhx-pce-stateful-lsp-sync-00 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. [Stateful-pcep] specifies a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP and maintaining of these LSPs at the stateful PCE. This document describes the mechanisms for incremental LSP Database (LSP- DB) synchronization as well as PCE control of the LSP-DB synchronization process. The IETF Secretariat _______________________________________________ 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
