[Pce] Re: [EXTERNAL] Re: PCE WG Minutes for IETF 124

["Andrew Stone (Nokia)" <[e-mail]>]

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) <ssidor=[e-mail]>
Date: Tuesday, November 18, 2025 at 7:38 AM
To: Andrew Stone (Nokia) <[e-mail]>, Marina Fizgeer <Marina.Fizgeer=[e-mail]>, Dhruv Dhody <[e-mail]>
Cc: [e-mail] <[e-mail]>, Marina Fizgeer <[e-mail]>
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
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) <[e-mail]>
Date: Tuesday, 18 November 2025 at 00:21
To: Marina Fizgeer <Marina.Fizgeer=[e-mail]>, Dhruv Dhody <[e-mail]>, Samuel Sidor (ssidor) <[e-mail]>
Cc: [e-mail] <[e-mail]>, Marina Fizgeer <[e-mail]>
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 <Marina.Fizgeer=[e-mail]>
Date: Monday, November 17, 2025 at 5:12 PM
To: Dhruv Dhody <[e-mail]>, Andrew Stone (Nokia) <[e-mail]>, Samuel Sidor (ssidor) <[e-mail]>
Cc: [e-mail] <[e-mail]>, Marina Fizgeer <[e-mail]>
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' <[e-mail]>; Andrew Stone (Nokia) <andrew.stone=[e-mail]>; Samuel Sidor (ssidor) <[e-mail]>
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>>
Sent: Monday, November 10, 2025 6:50 AM
To: Andrew Stone (Nokia) <andrew.stone=[e-mail]<mailto:andrew.stone=[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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/

Thanks!
Dhruv


On Sat, Nov 8, 2025 at 5:22 AM Andrew Stone (Nokia) <andrew.stone=[e-mail]<mailto:[e-mail]>> 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

Thanks to those who contributed to the minutes.

Please reach out to [e-mail]<mailto:[e-mail]> in case any correction needs to be made.

Thanks,
Andrew (PCE Secretary)

_______________________________________________
Pce mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>



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.