Hi Xian, please see [Jon] below... From: Zhangxian (Xian) [mailto:[email protected]] Sent: 22 February 2014 07:33 To: Jonathan Hardwick Cc: [email protected]; [email protected] Subject: RE: Comments on draft-minei-pce-stateful-sync-optimizations-01
Hi, Jon, Thank you very much for the constructive comments. Please see my reply inline, marked with [Xian]: From: Pce [mailto:[email protected]] On Behalf Of Jonathan Hardwick Sent: 2014年2月15日 2:35 To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [Pce] Comments on draft-minei-pce-stateful-sync-optimizations-01 Hi there I have reviewed this draft - here are my comments. Best regards Jon Section 3.2 Figure 2, I think the “sync done” PCRpt should have SYNC=0, not SYNC=1. [Xian]: Indeed. Thank you for spotting this typo. Section 5.2 If a PCC has to force full LSP DB synchronization due to reasons including but not limited: (1) local policy configured at the PCC; (2) no sufficient LSP state caches for incremental update, the PCC can set the D flag to 0. Perhaps I have misunderstood, but I think case (2) above doesn’t work. The PCC does not know that it has “no sufficient LSP state caches” until it receives the OPEN from the PCE and sees what DBv the PCE has sent. By then, the PCC has already sent its OPEN so it is too late to set D=0. To cover case (2) the draft needs a mechanism for the PCC to change its mind and tell the PCE that it is going to send a full snapshot, not a replay of the missing database updates. The simplest thing is probably for the PCC to bring the session down and then bring it back up again with D=0. [Xian]: It actually depends, IMHO. If it is due to the 1st reason listed above, then, it can decide before sending OPEN and set D=0. The cases as a result of the 2nd reason might be more complicated. Your analysis would be one of the cases, in which a PCC can detect the insufficient LSP state caches ONLY after it gets the DB version information from the other party. But if a PCC has no LSP state caches or incomplete (missing quite some LSP state or those of the DB version in between), I think it is possible that it can decide without even checking the DBv from the other party. Does this clarify? To include the case you described, how about we update the text as below? OLD: If a PCC has to force full LSP DB synchronization due to reasons including but not limited: (1) local policy configured at the PCC; (2) no sufficient LSP state caches for incremental update, the PCC can set the D flag to 0. [DD] NEW: If a PCC may have to force full LSP DB synchronization due to reasons including but not limited: (1) local policy configured at the PCC; (2) no sufficient LSP state caches for incremental update, the PCC can set the D flag to 0. Note a PCC may have to bring down the current session and force a full LSPDB synchronization with D flag set to 0 in the subsequent open message. [Jon] Looks good to me. Section 4 talks about the PCE having to mark its LSP database as stale, and then remove any stale LSPs at the end of the synchronization process. I assume that this does not apply in section 5. To avoid confusion, I think section 5 should state that the PCE does not mark its LSP database as stale if both it and the PCC have set D=1. [Xian]: Sure. I think we have already explained in Section 5. The last sentence of the paragraph below Figure 7 says: “Note that the PCE should not mark the existing LSPs as stale for incremental state synchronisation”. [Jon] Apologies, I missed that. In figure 7, I may have misunderstood section 4, but I don’t think this is how the T bit is specified. I don’t think T=1 forces the PCC to wait for a PCUpd before sending the initial snapshot as you have shown. I don’t think this substantially changes anything about section 5, so I suggest removing the discussion of the T bit from section 5. [Xian]：Section 4 describes how a PCE can force re-synchronization after the initial LSP-DB synchronization has been done. Section 5 talks about an alternative method for the initial LSP-DB sync. (i.e., incremental way). The idea here is allow PCE to control the sequence of incremental sync., the authors do see the value. However, you can see from the explanation of Section 5, setting the T=1 is NOT a mandate operation to enable incremental sync., but a feature optical and not covered by Section 4. The figure is drawn as shown because we intends to capture both features. Does this clarify your doubt? [Jon] I’m still unsure how triggered synchronizations are used by section 5.2. Here is the text that is confusing me: A stateful PCE MAY choose to control the LSP-DB synchronization process. To allow PCE to do so, PCEP speakers MUST set T bit to 1 to indicate this (as described in Section 4<http://tools.ietf.org/html/draft-minei-pce-stateful-sync-optimizations-01#section-4>). 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. The final sentence says that the PCE “can send a PCUpd”. It is not clear under what circumstances the PCC MUST wait for the PCE to trigger the initial synchronization. Please could you clarify? Do you mean that the PCE MUST trigger the initial synchronization any time the PCC and PCE have both set the T bit in their Open messages? Does that also apply in section 4? My understanding from section 4.1 is that this mechanism is intended to allow the PCE to sanity check the LSPDB and recover from internal errors after the initial session is established, not to trigger the initial synchronization: [...] it can be beneficial to be able to resynchronize this state even after the session has been established. The PCE may use this approach to continuously sanity check its state against the network, or to recover from error conditions without having to tear down sessions. Regards, Xian
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
