Venu, Thank you for the review. Please see inline below ###.
Ina From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of KONDREDDY VENUGOPAL REDDY Sent: Friday, March 22, 2013 4:58 AM To: pce@ietf.org Subject: [Pce] Comments on PCEP Extensions for Stateful PCE draft-ietf-pce-stateful-pce-02 Hi, Please find some review comments for draft - PCEP Extensions for Stateful PCE draft-ietf-pce-stateful-pce-02 1. In section 5.4 State synchronization "A PCE SHOULD NOT send PCUpd messages to a PCC before State Synchronization is complete. A PCC SHOULD NOT send PCReq messages to a PCE before State Synchronization is complete. This is to allow the PCE to get the best possible view of the network before it starts computing new paths." +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | |-----PCRpt, SYNC=1----->| (Sync start) | | |-----PCRpt, SYNC=1----->| | . | | . | | . | |-----PCRpt, SYNC=1----->| (Sync done)==> PCE doesn't exactly know that sync is complete at this moment | . | | . | | . | | | |-----PCRpt, SYNC=0----->| (Regular | | LSP State Report) Figure 3: Successful state synchronization In the above case, how would PCE know that synchronization is complete if there are no more PCRpt or PCReq received from PCC ? For example, if some LSPs were delegated to PCE in previous session. After session restart, PCE would not be able to send PCUpd messages to PCC until it receives first PCRpt message with SYNC=0. And PCC wouldn't send PCRpt until there is a change in LSP state. Suggestion: 1. we should have a mechanism for PCE to know that sync is completed at the end of last LSP state report. May be, we can send last report with SYNC=0. ### Please see version 03 of the draft 2. Rather than just allowing synchronization of LSP-DB immediately after initialization completion, we can also have a mechanism to trigger LSP sync when ever PCE wishes to get snapshot of LSP with PCC. This may be useful when PCE goes down and comes UP without disturbing TCP session or keepalive. ### I think you are talking about an internal failure of the PCE that does not cause failure of the session. I don't think this is a very common use case, and can be addressed by artificially bringing down the session, prefer not to complicate the existing mechanisms. 2. In section 5.4.1 state synchronization avoidance, suggest to change highlighted text below to "LSP state report from PCC" "If a PCC's LSP State Database survived the restart, the PCC will include the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain the last LSP State Database version sent on an LSP State Update from the PCC in the previous PCEP session." ### You mean report, right? I think this will always be the case in version 03, I don't think the clarification is needed. 3. In section 5.6.1. Passive Stateful PCE Path Computation Request/Response "Upon receiving a negative reply from a PCE, a PCC may decide to resend a modified request or take any other appropriate action. For each requested LSP, it also sends an LSP State Report carried on a PCRpt message to the PCE, indicating that the LSP's status is 'Down'." According to the text, PCC sends PCRpt message to the PCE, indicating that the LSP's status is 'Pending' only in case of positive path computation reply. In that case, we don't have to send PCRpt message to the PCE, indicating that the LSP's status is 'Down' in case of negative path computation reply. ### I don't think explicit state reporting is a problem, there is value in the pce knowing the state. Do you see an issue? Regards, Venu
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
