Hi Oscar, Thanks a lot for the comments, please see inline.
/Jan On 11/14/11 10:39 PM, "Oscar González de Dios" <[email protected]<mailto:[email protected]>> wrote: Dear authors of draft-crabbe-pce-stateful-pce-01, please find bellow my comments and questions on the draft, First of all, thanks for the valuable work on the stateful PCE topic and raising the discussions. Regarding delegation. What happens if the PCE-PCC connection is lost / closed? Good point. If the PCC-PCE connection is lost or closed, delegation is automatically revoked. Do we have to assume that delegation is only possible with persistent connections? Correct. We stated in the draft the PCE-PCC connection must be persistent. Do we assume that if connection is lost all delegations are revoked? Yes. Also, regarding delegation, can you elaborate more on what can and what cannot be done in the PCE when a LSP is delegated? A PCE can basically ask the PCC to set up and LSP (with parameters provided on the Update request), or tear down an LSP. A PCE can not add or delete an LSP – LSP addition/deletion is done locally at the PCC. In the case or restoration, if the PCC had delegated the LSP, who is responsible for starting the re-routing? The PCE. Will the PCE be aware of the failed element, and then proactively compute an alternative path, and proactively inform the PCC that it needs to update the path of the LSP? Yes, the PCE will be aware of a failed LSP. The PCC must send a status update whenever there is a state change on the LSP, such as an LSP goes down, a protection event happens (a switchover to secondary or FRR), … Regarding LSP information in the PCE, same issue . What happens if the PCE-PCC connection is lost / closed? Is the LSP info deleted after some time of not receiving news? Good points. Delegation is revoked immediately. What happens to an LSP is a matter of local PCC configuration: * The LSP may get delegated to a different PCE * The PCC may wait for a certain time and then tear the LSP down * The PCC may wait for a certain time and then turn the LSP to local CSPF/autobandwidth control We do not want to specify the local PCC behavior in the protocol specification document. Section 7.2 LSP-ID is local to the PCE-PCC session. If you use multiple PCEs, the LSP Object would only work in the correct PCE. Can the IDs overlap between different PCE-PCC sessions? Or must they be different? Session-local ID's can overlap. We introduced a symbolic name for each LSP, which must be unique, and it can be an ASCII name. Te symbolic name may also be persistent, i.e it may have to survive PCC restarts (a PCE needs an LSP identifier for the entire lifetime of the LSP, which may span across PCC restarts). It's too much overhead to carry an ASCII name on each LSP Report or Update, so we introduced the session-internal 32-bit ID. The first LSP State Report from the PCC to the PCE will establish the relationship between the LSP symbolic name and the session-internal LSP ID. Section 5.5.4 Redundant PCEs: You put the focus on the delegation. However, in case of redundant PCE, I would rather imaging the second PCE having a replica of the primary PCE. But, looking at the draft, it looks that in case of changing PCE, the second one will have to learn everything regarding state from scratch. That may imply that the second PCE will take some time to be fully operative… Primary and backup PCEs can certainly sync up between themselves. But we assume that LSP status reports go to both the primary and the backup during the PCC session. So there is no need to sync up the LSP state after a switchover. After a switchover, the PCC only needs to delegate the LSPs to the newly active PCE. Thus, correct me if I am wrong, seems that the state has only sense in a given PCE-PCC session. True? Not sure what you mean. A PCE may consider itself synced with a PCC only if there is an active session between the PCE and the PCC. Regarding the use cases, please considerer also another suggestion: LSP groups. When a LSP is created, it is typically associated to a group of circuits with whom some specific common behavior is needed. One example is to maintain a group of LSPs that you want to keep disjoint as much as possible. Currently, you can request a SVEC computation or add a list of exclusions, but you need to include all the details from the PCC. Having the state of each LSP in the PCE would simply this kind of operation. Moreover, in any later changes to the LSP, or in the event of restoration, if the group of LSPs has suffered modifications, in the case of the stateful PCE, it is straightforward to keep track of the changes. Otherwise, the PCC must keep track of them. We thought about this, but we think the concept of groups can be contained to the PCE. SVECs are required with a stateless PCE to keep it stateless when a PCC needs orchestration among multiple LSPs. But with the active stateful PCE, the PCE itelf is the orchestrator and it can groups LSPs whichever way it wants. Best Regards, Óscar ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
