Hello Dmytro, I ran into the same problem during my various tests. I noted that it is a pure PCC problem and behaviors remain the same whatever the PCE.
For me, IMHO, the correct behavior is the Cisco one i.e. when the primary PCE failed and PCC detects that the PCEP session goes down, it starts re-delegate to the secondary PCE all its own LSPs that have been initiated or updated (i.e. the LSPs configured by the PCC but delegated to the primary PCE) by the primary PCE. Regarding your questions: 1/ Some routers (see below) implement priority parameter for the PCE session. Thus, PCC will delegate tunnel to PCE with the highest priority. But, I agree that it is vendor dependent. From PCE side, it simply fill its LSP_DB with reported LSPs with delegate bit set to 1 or 0. But, this will not indicate that PCE is the primary or secondary. You could e.g. split your network in 2 independent part where each PCE is both primary for its part of the network and secondary for the other one. Again, it is a matter of vendor implementation to specify if a PCE is a primary or secondary one. From my knowledge, vendor prefer to propose redundancy within a single PCE (e.g. cluster of PCE). 2/ Agree with this expected behavior. Again, the PCE will not be able to determine that it is now the primary. But, from the re-delegation, it will check that its LSP_DB is in sync with LSPs reported by PCCs and made appropriate adjustment. Normally there is not if PCCs didn't remove LSPs when they detect that the PCEP session with the primary PCE goes down. 3/ This the normal behavior. Secondary PCE store in its LSP_DB the LSPs initiated by the primary PCE without delegation. When PCCs report to the secondary PCE the LSPs with delegation, the secondary PCE must preform reconciliation (see point above). Note: I also know that on Juniper, when PCEP session goes down, the router starts by removing all initiated LSPs. This behavior could be tune with the `lsp-cleanup-timer` parameter. By default, it was set to 0 (old JunOS version) and now set to 60 sec. Thus, by adjusting this timer to higher value e.g. 3600 sec. this perhaps let more time for the router to re-delegate the LSPs to the secondary PCE as expected. There is also a `delegation-priority` parameter which could influence the choice between primary and secondary PCE and thus the re-delegation (never try for the moment). Another way to improve this kind of high availability, is to setup a Virtual IP address between both PCE instance. Primary PCE is the one who got the Virtual IP address. Independently to the high availability scenario, this is also a problem that occurs when the PCE reboot i.e. all PCEP session goes down and depending of the configuration, some PCCs will removed their LSPs while other one keep them up during a time sufficient for the PCE (or a new one) to fire up again. Best Regards Olivier Le 24/06/2025 à 16:38, Dmytro Shypovalov a écrit : Dear PCE working group, I am working on a PCE for SR-TE and currently trying to implement dual-PCE redundancy. I prefer to follow the RFC and not implement any proprietary inter-PCE protocols unless absolutely necessary. PCEP has been so far not a very standard-friendly protocol in my opinion, because every vendor implements things differently and there is not much interoperability. I managed to make single-PCE scenario somewhat works, although there is different logic in handling state sync and LSP-ID state for different vendors. So my question is how dual PCE redundancy is supposed to work; let's say for now for PCE-initiated LSP only. RFC8231#section-5.7<https://datatracker.ietf.org/doc/html/rfc8231#section-5.7> describes the procedures, but again vendors implement it differently. Cisco delegates LSP to the PCE that initiated it, and reports to the other PCE (without delegate flag). and in case this PCE fails, redelegates to the second PCE and the LSP remain delegated to it forever. Juniper also delegates to the primary PCE and reports to the other without delegate flag, but if the primary PCE fails, Juniper does not redelegate, instead it waits a bit and then removes the LSP. My understanding is that it expects the secondary PCE to re-initiate the LSP at this point. I haven't tested Nokia, Huawei and others but wouldn't be surprised if they also have different ways of handling this. So my question is, how to properly implement dual-PCE redundancy? Is there a standard way or it relies on vendor-proprietary mechanisms? I think about the following logic: 1. When session comes up, wait until state sync (message with all zero's) + some timer; then * If received PCReports with delegate flag (and some of those matching our LSP) -> assume PCC elected us as primary PCE; send PCUpdate for these delegated LSP, send PCInit for our LSP not seen in PCReports * If received PCReports matching our LSP but without delegate flag -> assume PCC elected us as secondary PCE; do not send PCUpdate or PCInit * If did not receive any PCReports matching our LSP - [this is a tricky part - we can’t send PCInit because if 2 PCE send it simultaneously, PCC will complain] - maybe start a random timer and try to PCInit after it, so the other PCE will receive reports with our LSP? 2. When PCC re-delegates LSP to us -> assume we are now elected as primary LSP, send PCUpdate for delegated LSP and PCInit for LSP not seen in PCReports 3. When PCC removes LSP but they are still active on PCE side -> assume Juniper-style redundancy, send PCInit for those LSP I think this will work based on my observations so far but I want to ask PCE experts just in case - what is the IETF way and are there any implementations that interoperate with different vendors? Maybe the more intelligent approach would be implementing draft-ietf-pce-state-sync-09 but from reading it I'm not sure that will work in all scenarios including Juniper PCC. So it can add more problems with split brain while not solving the original issue. Please let me know what you think. Regards, Dmytro _______________________________________________ Pce mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- [logo Orange] <http://www.orange.com/> Olivier Dugeon Senior research engineer in QoS and network control Orange/INNOV/NET/WNI/IPN/iTeQ mobile : +33 6 82 90 37 85 [email protected]<mailto:[email protected]> ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
