Hello everyone, Firstly, Andrew and Samuel, thank you very much for your attention, detailed analysis, and answers.
Secondly, I'd like to discuss the technical aspects. We naturally want to interop with other vendors. But, as we know, there is no common standard solution that is widely supported. Even the decision on the transfer by PCC delegation for orphan LSPs (number 5) has not been fully determined. For example, the PCC delegates LSPs to PCE using preferences. The PCE doesn't accept some LSPs. Should the PCC delegate them to another PCE? Should it keep them? Or, during the transfer of orphan LSPs to the PCC, a new PCE with a higher priority join (while the PCC still has orphan LSPs). Furthermore, I believe such decisions should be made by the PCE, not the PCC. The PCE should know (as the network controller) which LSPs it wants. We can have several PCEs in the same group with different preferences for redundancy. But PCEs can also be in different groups for load balancing, and they can have the same preferences, each simply servicing its own part of the network. I don't know whether this is possible for a single PCC, but theoretically it's possible. Option 1 in my presentation – PCC shall send (PCRpt) all orphan LSPs – many unnecessary messages. Now about my suggestion. It requires a new development in both PCC and PCE (the same as in options 5 and 1). But these changes are not complicated. I don't have any new message. New TLV in LSPA object (shall be added to PCRpt), new notification type with also new sub-TLV. No additional big traffic, big number of messages. In case of delegation timer expiration, PCC shall send 1 notification to each PCE with active session. It will be triggering that PCE can take delegation, but also that all LSPs, delegated to disconnected PCE, now are not delegated to any PCE. Then PCE can update his LSP DB. No need to send big number of orphans LSPs. For take delegation by PCE – we can add flag to PCInit and to use PLSP-ID = 0 (with sub-TLV PCE address) – the meaning of it is that all orphan LSPs were delegated to this address shall be re-delegated to this PCE. Or PCE can do it one by one. Thank you once again! Best regards, [Logo]<https://ribboncommunications.com/> Marina Fizgeer Sr. Manager, Systems Architecture | Ribbon M +972.544860016 Petah Tikva, Israel [Banner]<https://ribboncommunications.com/?_gl=1*6qlbuc*_gcl_au*MjA3NzE5OTk5NC4xNzI4NDE0NDY4*_ga*NTIxNzg1MDgxLjE3Mjg0MTQ0NjM.*_ga_VCEZ9Q3S3Y*MTcyODQ1MjEzMC4yLjEuMTcyODQ1MjE4OS4xLjAuMTA4NjExNTU4> From: Samuel Sidor (ssidor) <[email protected]> Sent: Wednesday, November 19, 2025 10:46 AM To: Andrew Stone (Nokia) <[email protected]>; Marina Fizgeer <[email protected]>; Dhruv Dhody <[email protected]> Cc: [email protected]; Marina Fizgeer <[email protected]> Subject: Re: [Pce] Re: [EXTERNAL] Re: PCE WG Minutes for IETF 124 Hi Andrew, In RFC8231 , we have just “SHOULD” for PCC automatically re-delegating to other PCE, so PCC implementation, which is not doing it is still valid. Do we want to update that RFC then to enforce that requirement (e.g. based on some capability)? What I consider as bigger problem is that we have multiple behaviors implemented across multiple vendors and there is no capability advertised to indicate which of them will be used, so PCE does not have reliable way to figure out whether it needs to do anything (explicit reclaim delegation request) or not. If automatic re-delegation is not supported by PCC, then PCE can just guess what is the timer value used by the PCC and try to do periodic polling. That is making it even worse. I agree that the solution proposed in the draft will not solve it for existing implementations, but I personally prefer to use that draft for at least: * Introducing capability on PCC side to advertise which model is supported (currently enabled or used). At least for updated implementation, decision logic on PCE will be simple and straightforward. If specific implementation will explicitly advertise that it does not support automatic-redelegation (e.g. because HA model of that specific vendor does not need it), then it can also advertise re-delegation timer value or address of PCE to which LSP is delegated on top of that. * Describe potential solutions on PCE side for existing PCC implementations (e.g. state-sync between PCEs), recommendations for deployment (e.g. having re-delegation timer configured to same value on all PCCs, so PCE can assume some value of that time based on one or more successful attempts to re-delegate) Regards, Samuel From: Andrew Stone (Nokia) <[email protected]<mailto:[email protected]>> Date: Tuesday, 18 November 2025 at 19:16 To: Samuel Sidor (ssidor) <[email protected]<mailto:[email protected]>>, Marina Fizgeer <[email protected]<mailto:[email protected]>>, Dhruv Dhody <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Marina Fizgeer <[email protected]<mailto:[email protected]>> Subject: Re: [Pce] Re: [EXTERNAL] Re: PCE WG Minutes for IETF 124 Hi Samuel, * If Marina or anybody else is trying to build PCE, which is interoperable with such PCC, then they will need to solve that problem from PCE side. Fair point, but, if those/any implementations don’t implement a new proposal extensions either, then it still will not be interoperable. It seems to me if there’s already a RFC defined interoperable solution (delegate on-orphan), shouldn’t the motivation and drive be in that direction to get implementation rather than add more to the protocol behaviour and require changes to both PCC and PCE? Thanks Andrew From: Samuel Sidor (ssidor) <[email protected]<mailto:[email protected]>> Date: Tuesday, November 18, 2025 at 7:38 AM To: Andrew Stone (Nokia) <[email protected]<mailto:[email protected]>>, Marina Fizgeer <[email protected]<mailto:[email protected]>>, Dhruv Dhody <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Marina Fizgeer <[email protected]<mailto:[email protected]>> Subject: [Pce] Re: [EXTERNAL] Re: PCE WG Minutes for IETF 124 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi all, Andrew - I agree with you that this solution seems to be most simple (and that’s why I believe both - Nokia and Cisco has it implemented), but I know about PCC at least from one other vendor, which does not seem to support such behavior (no automatic re-delegation by PCC). If Marina or anybody else is trying to build PCE, which is interoperable with such PCC, then they will need to solve that problem from PCE side. Marina - I would personally prefer simpler solution, which is slightly less optimal from encoding POV, but which does not need to add support for 3 new notification types and does not need advertisement of delegation timer value of other PCEs - just use extension introduced in: https://www.ietf.org/archive/id/draft-fizgeer-pce-redundancy-extensions-00.html#name-lsp-object<https://www.ietf.org/archive/id/draft-fizgeer-pce-redundancy-extensions-00.html#name-lsp-object> So probably solution #1 from your list of possible solutions. When delegation timer expires, “Delegation Address” flag would be cleared for all impacted LSPs. All PCEs will know delegation can be reclaimed for those LSPs. It can be still combined with new capability indicating whether PCC can do automatic re-delegation described by Andrew - if yes, then such notifications can be skipped as PCC will take of re-delegation anyway. Regards, Samuel From: Andrew Stone (Nokia) <[email protected]<mailto:[email protected]>> Date: Tuesday, 18 November 2025 at 00:21 To: Marina Fizgeer <[email protected]<mailto:[email protected]>>, Dhruv Dhody <[email protected]<mailto:[email protected]>>, Samuel Sidor (ssidor) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Marina Fizgeer <[email protected]<mailto:[email protected]>> Subject: Re: [EXTERNAL] [Pce] Re: PCE WG Minutes for IETF 124 Hi Marina, I'll raise the same comment/question I had on the mic at ietf-124: what are the concerns with PCC just delegating the lsp to another active session when it becomes an orphan? This is an option specified in RFC8231 Section 5.7.5 and RFC8281 section 6. Yes, your slides do point this as being an option ("possible solution: bullet 5) but does not seem to outline why it's not an acceptable solution. As we discussed in session and you do indeed have on your slides, this would simply be a local preferencing, regardless if there's 1,2,3 or 5 PCEs. Would this not be simpler? It involves no new extensions, and no new message exchange or definitions, and already RFC specified. My concerns with a notify-like behavior to require PCE to ask for delegation is from a few angles, such as: * You now need to notify all PCE(s) everytime delegation state changes, per path. This is noise that did not necessarily exist before. A notification will happen both for delegation removal, and re-delegation (when no longer orphaned) -> to all connected PCEs. * The final delegation is non-determistic if there's > 2 PCEs. If there are 3 or more, and the active one fails, it will be a race condition between the other PCE's as to which one will succeed in grabbing delegation. Perhaps it does not matter at the end of the day, but it does become an operational consideration and aids to troubleshooting headaches * There's additional overhead for -all- PCEs and affected PCC interaction: notify not delegated, ask for delegation (race condition), then report delegation (to the winning PCE) and notify delegation info (to the other PCEs). It's quite a lot more messaging, compared to just PCC simply sending PcRpt+Delegate to the next-best-preference PCE * Consider that a death of PCE is likely to affect a large number of PCCs, the above bullet points can involve a lot of messaging and processing. Thanks Andrew From: Marina Fizgeer <[email protected]<mailto:[email protected]>> Date: Monday, November 17, 2025 at 5:12 PM To: Dhruv Dhody <[email protected]<mailto:[email protected]>>, Andrew Stone (Nokia) <[email protected]<mailto:[email protected]>>, Samuel Sidor (ssidor) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Marina Fizgeer <[email protected]<mailto:[email protected]>> Subject: RE: [EXTERNAL] [Pce] Re: PCE WG Minutes for IETF 124 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hello, Please help me move forward with the PCE Redundancy issues and my proposal. We discussed the need for a dedicated additional meeting to discuss existing options and my proposal. I've tried to analyze this in the attached document. What should be the next steps? Thank you in advance. Best regards, [Logo]<https://ribboncommunications.com> Marina Fizgeer Sr. Manager, Systems Architecture | Ribbon M +972.544860016 Petah Tikva, Israel [Banner]<https://ribboncommunications.com/?_gl=1*6qlbuc*_gcl_au*MjA3NzE5OTk5NC4xNzI4NDE0NDY4*_ga*NTIxNzg1MDgxLjE3Mjg0MTQ0NjM.*_ga_VCEZ9Q3S3Y*MTcyODQ1MjEzMC4yLjEuMTcyODQ1MjE4OS4xLjAuMTA4NjExNTU4> From: Marina Fizgeer Sent: Tuesday, November 11, 2025 5:42 PM To: 'Dhruv Dhody' <[email protected]<mailto:[email protected]>>; Andrew Stone (Nokia) <[email protected]<mailto:[email protected]>>; Samuel Sidor (ssidor) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: RE: [EXTERNAL] [Pce] Re: PCE WG Minutes for IETF 124 Hi, dear friends, Following up on my presentation and our discussion at the EITF 124 PCE meeting, I am sending the supplement a presentation with a detailed description of the problem, the options we have thought about and our proposed solution, which seems to me simple to implementation and flow itself. Your opinion is very important to me. Thank you in advance. Best regards, [Logo]<https://ribboncommunications.com/> Marina Fizgeer Sr. Manager, Systems Architecture | Ribbon M +972.544860016 Petah Tikva, Israel [Banner]<https://ribboncommunications.com/?_gl=1*6qlbuc*_gcl_au*MjA3NzE5OTk5NC4xNzI4NDE0NDY4*_ga*NTIxNzg1MDgxLjE3Mjg0MTQ0NjM.*_ga_VCEZ9Q3S3Y*MTcyODQ1MjEzMC4yLjEuMTcyODQ1MjE4OS4xLjAuMTA4NjExNTU4> From: Dhruv Dhody <[email protected]<mailto:[email protected]>> Sent: Monday, November 10, 2025 6:50 AM To: Andrew Stone (Nokia) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: [EXTERNAL] [Pce] Re: PCE WG Minutes for IETF 124 Hi, Thanks Andrew! I made some tiny edits, you can find the latest version at - https://datatracker.ietf.org/doc/minutes-124-pce-202511061430/<https://datatracker.ietf.org/doc/minutes-124-pce-202511061430> Thanks! Dhruv On Sat, Nov 8, 2025 at 5:22 AM Andrew Stone (Nokia) <[email protected]<mailto:[email protected]>> wrote: Hi PCE WG, Please find the minutes for PCE WG session at https://datatracker.ietf.org/meeting/124/materials/minutes-124-pce-202511061430-00.md<https://datatracker.ietf.org/meeting/124/materials/minutes-124-pce-202511061430-00.md> Thanks to those who contributed to the minutes. Please reach out to [email protected]<mailto:[email protected]> in case any correction needs to be made. Thanks, Andrew (PCE Secretary) _______________________________________________ Pce mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
