Hi Dhruv, Thanks for the comments, please see inline.
/Jan On 11/1/11 11:49 PM, "Dhruv Dhody" <[email protected]<mailto:[email protected]>> wrote: Dear Authors, Here are a few comments – 1. In section 5.2: “Path Computation State Report (PCRpt): a PCEP message sent by a PCE to a PCC to report the status of one or more LSPs.” I think there is mistake, PCRpt is sent from PCC to PCE based on the rest of the draft. Yes, indeed. We will correct the text. In fact, the PCRpt can be sent from a PCE to another PCE to sync the state between PCEs. 2. In section 5:3: It’s important to add correlation between PCE Capability Discovery by IGP and via OPEN. Do you suggest to use both methods interchangeably? We think both are required. Capability discovery by IGP is clearly needed, but we wanted to limit the scope of this draft to PCEP and describe stateful capability discovery by IGPs in a separate draft. Capability negotiation in PCEP is still needed - both PCEP speakers need to confirm at the beginning of a PCEP session that the discovered capabilities are indeed supported. 3. Multiple Timers needs to be described to handle Statefull sync making sure PCC finishes the synchronization and send PCRpt with SyncDone=1 within a timeframe. You can also consider adding state synchronization as a part of Statefull Session Up. I.e. PCEP Statefull session is declared up only when PCC sends PCRpt with SyncDone=1. The timer is good idea. It's value could be a parameter negotiated at the beginning of the PCEP session. We think it's better if the synchronization is done after the PCEP session is up – then we know for sure that the channel between PCEP Speakers is up (we have Keepalives going on). Also, a PCE may want to start to service requests or set up LSPs even if it's not fully synchronized with a PCC (whether a PCE does this is an implementation/configuration issue). 4. In Section 5.5.4 you touch on Redundant Statefull PCE, we should explore backup PCE in more details. Agreed. Another mechanism can be Primary and Backup Statefull PCE have a direction session and relationship to handle primary failure in a much faster and secure mechanism. Agreed, this is another viable method to sync up the Primary and Backup PCEs. Here, the PCC will only need to send PCRpt messages to the Primary PCE, which would offload the PCC (it would only have to send PCRpt messages to the Primary PCE). After a switchover, the new Primary PCE and the PCC still need to sync up, though (race conditions, messages in transfer, etc.). We described what we think is the simplest possible mechanism that makes no assumption on how PCEs are related to each other or communicate with each other. But we agree that it can be just a starting point for a more detailed discussion. 5. Wrt to delegation, PCE updates LSP parameters and send PcUpd to PCC, if PCC apply Make-Before-Break policy where new applying new parameters has failed, it’s important for PCC to send PCRpt stating that LSP is up but without updating the new parameters as suggested by PCE in PCUpd. Agreed. We'll add it to the text. 6. Wrt to section 6.1, ERO is used to carry the path as specified by PCE, RRO is also used if LSP is setup along the path. I am not sure why you need both ERO and RRO, can you give a use case? If the PCE specifies a loose route, i.e. the ERO does not contain all hops, the PCC will use local CSPF to route the LSP. The PCC can report to the PCE how the LSP got routed (if route recording is enabled on the LSP). Similarly am not sure what is the purpose of IRO in PCUpd? If the PCE specifies a loose route, it may still want the PCC's local CSPF to route the LSP through a set of nodes specified in the IRO object. Sorry for nit-picking I guess! :D Really good points, thanks for bringing them up. Also few things that should be considered – 1) Synchronization Vector: If PCC request some LSP to be computed together I think this relationship should continue in Statefull PCE so PCRpt and PCUpd should continue to support that We don't need the Synchronization Vector for LSPs delegated to a PCE. The PCE not only computes the paths for delegated LSPs, but also decides when to set up each LSP. The PCE can synchronize LSP setups within a single PCC, or between PCCs. Basically, delegated LSPs are under the control of the PCE. Also, a PCC must not request a path computation on a delegated LSP (Section 5.6.2; basically, an LSP is either under PCE's control or under local control, never both). We don't need synchronization for LSP State Reporting – while synchronization is required for path computations/requests, state reporting is by definition asynchronous (events on LSPs occur asynchronously, LSP setups may finish out of order even for synchronized LSPs, etc.) 2) Statefull PCE becoming Bottleneck: This needs to clearly specified, mechanism like Overload PCE notification should be enhanced to handle Statefull PCE, Right now we are relying on message-level flow control built into PCEP (basically, TCP :-) ). If a PCE is overloaded and can't process one or more PCRpt messages from a PCC, it will loose state and state resynchronization must follow. The simplest method to resync is to drop the PCEP session with the PCC and re-establish it when the overload condition disappears. We think that's a good starting point, but we may want to come up with more sophisticated flow control mechanisms (Robert Raszuk brought up this point as well). we can explore option of PCE-PCE communication (intradomain scope) to handle Primary Statefull PCE failure/overload conditions. The clear benefit would be only 2 entity (Primary PCE and Backup PCE) will be involved, otherwise all PCC in the system must send PCRpt with Delegate=1 for all LSP. Good point – we should discuss this further. Hope we have a fruitful discussion in Taipei. Looking forward to it. Regards, Dhruv *************************************************************************************** Dhruv Dhody, Senior Technical Leader, Huawei Technologies, Bangalore, India, Ph. +91-9845062422<tel:%2B91-9845062422> This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
