IETF 124 PCE WG Minutes

Thursday November 6th 2025, Session I
09:30 - 11:00 (Montreal, EST)
14:30 - 16:00 (UTC)

• Chairs: Dhruv Dhody, Julien Meuric
• Secretary: Andrew Stone
• AD: Ketan Talaulikar
• Note Taker: Andrew Stone
• Slides
• Video
• Chat-log
• Meetecho Recording

Introduction

1.1. Administrivia, Agenda Bashing (Chairs, 5 min) [5/90]

1.2. WG Status (Chairs, 5 min) [10/90]

1.3. State of WG I-Ds, open issues, and next steps (Chairs, 10 min) [20/90]

• [Ketan] Concerns raised regarding moving Francesco to the contributors section. There's ways to handle when people retire, but they should still get credit. Can help work on this, and also a decision of the co-authors.
• [Dhruv] Author's decision but thanks for clarification.
• [Rakesh] - Regarding stateful-pce-autobw-update: RFC8733 says MPLS-TE auto bandwidth, we have this I-D "draft-ietf-pce-stateful-pce-autobw-update" that updates RFC8733 with few things - another update we did was that the LSP now includes the SR LSP (sr-mpls and SRv6).
• [Cheng] We have a set of documents of path segment, 6 or 7, trying to move them forward. First would be the spring doc, going to address comment from Bruno to hopefully get that one done then come back to here.
• [Dhruv] Sounds good, remember about the IANA codepoint - timing is important. We can progress multiple together including with SPRING.

Segment Routing

2.1 SR P2MP Policy (Hooman Bidgoli, 10 mins) [30/90]
draft-ietf-pce-sr-p2mp-policy

• [Dhruv] It's second in our queue, so should be going soon. We will ask for an early RTGDIR/OPSDIR review.
• [Andrew] Don't be spooked by chaos of the diff, it's still same technical content just restructured.

2.2 SRv6 MSD Limitation (Yao Liu, 10 mins) [40/90]
draft-liu-pce-srv6-msd-consideration

• [Dhruv via chat] It is interesting the RFC9603 says "MSD capabilities" not "MSD values" - there is some wiggle room...
• [Zafar] This draft prompted me to ask for the extra 5 min session, there is an overlap with how this is done with SRv6 vs SR-MPLS use case where first is adjacency sid, the other draft. We had a conversation offline with authors and we said let's collaborate on this one. We will continue that.
• [Dhruv] Thanks, Yes it's better if we consolidate the draft than do it seperately for SRv6 and SR-MPLS.
• [Dhruv] Is it good idea to mention the type explicitly, or just make it more generic? In generic way, it doesn't need to be updated for new segment types. In one interpretation it does not say SRv6 MSD values but capabilities, so already wiggle room.
• [Zafar] Because the behavior is whether known to PCE, whether we need R flag or not
• [Andrew] I like idea of generically saying if it exhibits behavior, but since there's so many types it's easy to overlook or analyze the consequences. If two implementations don't align it won't work. I think we will have to list out the known types, but can be leave it open generically, maybe.

2.3 BSID Extensions (Samuel Sidor, 5 mins) [45/90]
draft-sidor-pce-binding-label-sid-extensions

• [Andrew] If the BSID requested cannot be used, and PCC allocates one, if the LSP bounces, can it use the one requested or still self allocated?
• [Samuel] When conflict is resolved, it can use the requested one at any time.

Stateful PCE

3.1 Signaling Multipath (Samuel Sidor, 10 mins) [55/90]
draft-ietf-pce-multipath

• [Dhruv] Just want to agree on the comment if this is going beyond SR Policy architecture, especially adding the backup and opposite direction thing. Comment was it's always been in PCEP, but at same time SR Policy does not mention it. As a group, what is our conclusion?
• [Ketan] Comments came from me, my concern was the segment list used only as active and backup thing. It's not that it's not covered but kind of a violation since SID List is used for load balancing not backup. Backup is at candidate path level. If used for something other than SR Policy just clarify that.
• [Andrew] Backup SID list is not for the unicast but for the P2MP. One of the drafts discusses you can program hop by hop backups. The original intention was for the point to multipoint.
• [Samuel] There's an explicit reference in the draft for it too.
• [Ketan] Is the Segment list there in the P2MP policy?
• [Hooman] In the P2MP policy there is a backup for every single sid downloaded, can have a backup.
• [Andrew] Been a while since I read the intro, only thing, maybe in the intro, since it looks like SR Policy oriented but it's really a generic PCEP draft we should make sure that's clear.
• [Dhruv] Have it open, says it's optional for certain use cases such as P2MP SR Policy. Just want to confirm it covers the concern.
• [Andrew] Yeah if it said this is for unicast i get the concern, but it doesn't
• [Dhruv] But you don't bar it also.
• [Andrew] True. So could someone go do this for unicast, draft does not bar it.
• [Ketan] Right now the way things stand it's for weighted load balancing not active backup.
• [Andrew] If we want to call it out and say unicast can't do this then that's an option.
• [Samuel] Yeah can explicitly mention it's for P2MP.
• [Andrew] We don't also want to create a bunch of circular dependencies also.
• [Dhruv] Any thoughts on opposite direction? That's also something not explicitly mentioned but we do co-routing often.
• [Zafar] Why P2MP cannot have the same way as P2P has with different candidate path level?
• [Andrew] The design of p2mp with the replication segment, with the tree, there was a use case to not rely on underlying IGP to carry all those SIDs. It just needs the next-hop replication sid. Want to protect outgoing IGP, encode the backup SID list and tie them together. Not the same pattern as unicast.
• [Hooman] When it comes to P2MP there's other challenges with LFA and ingress (in hardware) - need a loop in data path. For P2MP there's two ways to do LFA, use the unicast and LFA based on unicast and when you do that need to do two loops in data path. Otherwise if no unicast SR and want LFA / fast reroute, only option is separate tree in the P2MP Tree itself setup via the same mechanism and use that as a bypass.
• [Zafar] Maybe can discuss offline.
• [Samuel] About opposite, the use case is circuit style. It's pointing to that one.

3.2 Bounded Latency (Quan Xiong, 10 mins) [65/90]
draft-xiong-pce-detnet-bounded-latency

• [Dhruv] Can we only use one sub object type possible? or could I have multiple of these, it's not clear to me in the draft so if that can be clarified
• [Quan] You're correct there is only one type but there can be different types for different sub objects.
• [Dhruv] I would prefer if there is a one to one mapping like your previous example, would make the encoding simpler instead of multiple subobjects for each type. Anyways we can discuss it. What is the status in detnet?
• [Quan] Yes we reference to the data plane text for the queueing solutions but the information has not reached consensus.
• [Janos] Thanks for the presentation, this was not recently presented to detnet. Still no consensus on this so individual contribution. Text referenced is a working group document. We are hopefully now moving to adoption of individual drafts on queueing solution. New additional work of interest is an I-ID presented on Monday on multidomain detnet, pce based. This work here might benefit or progressing with alignment, latency bound might be benefit for a domain.
• [Quan] Please continue to work with the detnet WG and WG review. Adoption we will wait and coordinate with detnet WG for now.

3.3 Support for BFD parameters (Marina Fizgeer, 5 mins) [70/90]
draft-ietf-pce-pcep-bfd-parameters

• [Zafar] I would like to see explicit statement that people can use profile id. There's a hesitation in my mind when something is configuration data from different sources not through PCEP. Yes, respect WG is working on it. For people who don't want to do this, statement upfront that there's alternatives available.
• [Dhruv] Propose text.
• [Dhruv] Adding capability for PST setup separately, is that something needed/done/useful? if anyone has thoughts, otherwise come to the mailing list.
• [Zafar] Always prefer for keeping it simple, operator knows these things when they deploy it. Operators know that kind of signaling they do support so I would prefer just one common capability.
• [Andrew] No comment or opinion on per PST setup, but just wanted to say I agree with Zafar in general that operators know that they deploy, however not in regards for topology or makeup of the nodes. With autonomous behavior on the PCE or some automation mechanism, it may be doing its own thing without a human and a policy may ask for something like BFD. If the PCE doesn't know what the nodes can do, it can run into trouble when trying to signal or perhaps should exclude that node.
• [Reshad] Question To Zafar, keep it simple for the vendor or operator? Also keep in mind there's software upgrades. As co-chair of BFD thank you for updating for the comments.
• [Zafar] I see you do it for configuration.

3.4 PCE Redundancy Extensions (Marina Fizgeer, 10 mins) [80/90]
draft-fizgeer-pce-redundancy-extensions

• [Dhruv] Let's focus on: if that is real problem or not, later we can discuss solution aspects, encoding etc. Can get more feedback if folks thinks this is a problem.
• [Marina] We thought about each option but there's trade offs.
• [Dhruv] Let's see if people think if this is a problem that needs to be fixed as we have various other documents like state sync which can help and mechanism like PCE asking for control. Are those existing mechanism not enough then we can worry about the solution aspects.
• [Samuel]- From my perspective PCE initiated delegation is complicated, each vendor implements it slightly different ways. Some improvement is useful. Possible ways to solve it via some existing state synchronization between PCEs. I consider this a useful draft.
• [Dhruv] Think it would be good to fully explain the problem first. Try to explain scenario exactly in which you don't have a session. But also with other mechanism, why are they not sufficient? Then can jump into solution space. Convincing more people new extension is needed would be useful.
• [Marina] Additional problem LSP created by PCE1 is updated to PCE2 as well, but without delegation information
• [Dhruv] Just the state sync draft has not let the WG so if we want to update it there also a discussion
• [Marina] Will not solve all problem, but in addition PCE2 shall know when it is orphan and can take delegation.
• [Dhruv] The question is whether in your solution with notification needed? I believe state sync draft can handle it, you have the state sync information. Whether you need notification not sure.
• [Andrew] Is any reason why after it becomes orphaned to not just have PCC give delegation to PCE
• [Marina] What if you have two or three PCEs?
• [Andrew] You pick one. With preferencing. Pick the next one in order.
• [Marina] It's possible to use preferences.
• [Dhruv] And is there in the state sync draft
• [Andrew] In our implementation PCC gives back delegation to a backup PCE when it goes orphan
• [Marina] I think our solution is simpler and more straight forward.
• [Andrew] If there is PCE2 and PCE3, would they also not fight over taking delegation?
• [Samuel] Some implementations do delegation by themselves and some not.

3.5 LSP validation Extensions (Marina Fizgeer, 5 mins) [85/90]
draft-fizgeer-pce-lsp-validation-extensions

• [Dhruv] Folks please provide feedback if this is useful or not.
• Insufficient time for comments.

3.6 Precision Availability Metrics (Luis Contreras, 5 mins) [90/90]
draft-contreras-pce-pam

• [Rakesh] Just repeating comments gave in TEAS, draft can explain how to do path computation. Will be useful.
• [Luis] Thanks - we will address them

If time permits

4.1 SID Optimization comment and discussion (Zafar Ali, 5 mins) [if time available]
draft-all-pce-srv6-policy-sid-list-optimization
draft-ali-pce-sr-policy-msd-consideration

• Not presented, insufficient time