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. 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? 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? 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. Regards Jon -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Zhangxian (Xian) Sent: 08 July 2013 10:59 To: [email protected] 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) ________________________________________ 发件人: [email protected] [[email protected]] 发送时间: 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 [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
