IETF 123 PCE WG Minutes

Friday, 25th July 2025, Session I
09:30 - 11:00 (Madrid, Tapces)
07:30 - 09: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]

• [Ketan] Note on early codepoints, even if they expire and not approved, they still will remain in expired state until chairs and WG decide to return or deprecate. If it happens, too many instances going to IESG, then I am not inclinded to go to IESG, and they will stay in expired state. Doesn't make sense to keep asking for approval.

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

Segment Routing

2.1 SR-Algorithm in PCEP (Samuel Sidor, 10 mins) [30/90]
draft-ietf-pce-sid-algo

• [Dhruv] Reminder to group, this has already finished WG LC, these are comments handled after AD review and Shepherd Report. As a group, we need to make sure there is still consenses, which is why this is presented here to WG. Any feedback please raise them now.

2.2 BSID Extension (Samuel Sidor, 5 mins) [35/90]
draft-sidor-pce-binding-label-sid-extensions

• [Boris] Could you clarify the point of D flag, what's point to instantiate LSP while it's in down state.
• [Samuel] For temporary state, such as in case there is a conflict. We'll keep LSP in down state because conflicting, but can replace what is currently also being removed. For a short period of time, it will be down, but then can come up.
• [Dhruv] My suggestion would be in the document and add examples for these flags on how they are used. An example of how these flags play a role would help.
• [Samuel] Yes can add to the motivation section.

2.3 MSD Considerations (Zafar Ali, 5 mins) [40/90]
draft-ali-pce-sr-policy-msd-consideration

• [Andrew] Someone I was chatting with last night about this put it well, this is like finding cash in your pocket, we found one extra SID and it's useful. Change is minor. Support adoption.
• [Dhruv] Did we do a survey of vendors, is everyone implementing it in this way or any confusion. It's not very explicit. Is there confusion or are there other ways to fix it.
• [Andrew] The text says the number of SIDs, doesn't evaluate the type. Based on the raw number only. So if someone reads the text and follows it literally they should b be validating.
• [Duruv] What are current implementations currently doing?
• [Andrew] Nokia's implementation does respect and support existing validation rules and I support the adoption as it would give us an extra SID.
• [Dhruv] This text doesn't explicitly say at the time of imposition or at the time of calculation. We should clarify. Should we do it via a flag or just updating RFC.
• [Andrew] The flag is needed because PCC in the network might also have a validation check on their side, that PCE is not sending them bad data. Need the flag to make it backwards compatible.
• [Dhruv] Suggest discussion on the list. Worry the flag is when do I not set it.
• [Zafar] There are 2 questions: does it say really PCC or PCE. In the current slide text from RFC says PCE must not send number of SIDs exceeding. It's about the path, not the encapsulation that the packet will actually take. It's about the ERO. Our PCE implementation also validates these rules. This is important improvement for MSD.
• [Yao] About the last bullet, when ADJ SID is first SID in sid list, the top SID is not imposed on the packet. Is this a must or implementation specific.
• [Zafar] It's a must because if you put it on packet its not local to the next router and will be round. It's a MUST in any implementation. It's indicator of outgoing interface.
• [Yao] Maybe could it be more generic, when the first SID is node SID we have the reduced mode. Wouldn't node sid not be put in SID list as well. Could you consider the same if it's node SID.
• [Zafar] Reduced mode is very specific to SRv6 and different since it reduces by carrying it in the DA. if it's DA you must carrry because you need to carry that. Don't think there's any overlap with reduced mode.
• [Dhruv] lets discuss more on the list on this part.

2.4 SRv6 SID List Optimization (Zafar Ali, 5 mins) [45/90]
draft-all-pce-srv6-policy-sid-list-optimization

• [Dhruv] Chairs will discuss on adoption and get back to you. Thanks for making progress.

Stateful PCE

3.1 Operational Clarification (Andrew Stone, 5 mins) [50/90]
draft-ietf-pce-operational

• [Boris] I would vote for B option. Keep sending but throttle.
• [Andrew] Question for me is what defines significance. What kind of rule set.
• [Boris] Yes it will add additional complexity.
• [Boris] Agree, so either A or B, not C.
• [Samuel] Maybe one more option is just close the session. If we close the session and reopen when overload is complete then we can resync and it can work with latest state. Dropping reports and deciding which to drop can be complex as mentioned already. If we close session, then PCE can selectively control which sessions to close.
• [Andrew] Reiterating, suggest PCE can kill some sessions until read to bring back and sync in.
• [Samuel] Can do it selectively.
• [Ketan] This kind of scenario is there in BGP already. Perhaps consider some lessons learn there and some of this is in implementations.
• [Dhruv] I saw extended LSP-DB 3 times but I don't see an advantage for that. I am thinking from readability point of view not the content one.
• [Andrew] Main thing trying to capture and isolate independent state from the PcRpts and how you want to do intended states.
• [Andrew] Will take a look to see what can be simplified out.

3.2 Amendments to Stateful PCEP (Andrew Stone, 5 mins) [55/90]
draft-many-pce-stateful-amendment

• [Boris] Do you have backward compatibility section there?
• [Andrew] Yes, there's a few sentences. Basically to have a functioning PCE you already need to handle a delegated path for a down LSP. Generally those PCE already have an implementation to deal with, you kind of already have to handle it so the handling logic is already there.

3.3 LSP State Reporting Extensions (Samuel Sidor, 5 mins) [60/90]
draft-sidor-pce-lsp-state-reporting-extensions

• [Quan] I have two concerns, the first one it will be better to define clearly the term transit LSP -- first time seeing that word. What'd the difference between explicit path and loose path or strict path. Why are we defining another explicit path and dynamic path. We have defined strict and lose in RFC.
• [Samuel] We can add more details about definition of transit LSP. For new explicit or dynamic the strict or loose hops are the flags for the hop itself. So basically the single path can go strict hops or loose hops. Even if operator define path explicitly, they could include loose hops. We are saying path is computed dynamically. To signal its defined by operator. Even if computed by PCE it can still be signalled by PCE and some can be strict or loose.
• [Dhruv] Suggest adding this as an example in the document, think this comment came last time and you added text, maybe example would be the next step.

3.4 PCEP for Multipath TE Directed Acyclic Graph (MPTED) Tunnels (Vishnu Pavan Beeram, 5 mins) [65/90]
draft-beeram-pce-pcep-mpted

• No comments due to time.

Others

4.1 Topology Filter (Quan Xiong, 5 mins) [70/90]
draft-xpbs-pce-topology-filter

• No comments due to time.

4.2 Source Address Validation (Xueyan Song, 5 mins) [75/90]
draft-song-pce-pcep-sav

• [Dhruv] You're asking the correct questions, please start some discussion on the list.

4.3 Precision Availability Metrics (Luis Contreras, 5 mins) [80/90]
draft-contreras-pce-pam
- [Dhruv] Thanks for updating. It is not clear to me - how to take those metrics in consideration when doing path computation? How do I track this over time series. If I don't know the path in advance how do I make that histogram.
- [Luis] Got it, thank you.

4.4 PCEP over QUIC (Feng Yang, 5 mins) [85/90]
draft-yang-pce-pcep-over-quic

• [Dhruv] My suggestion would be to keep discussing with the other authors, like netconf over quic, bgp etc.
• [Andrew] Thanks for updating, I'm also still unclear of the benefits. For example, I'm not aware of anyone having issues with head of line blocking due to keepalives, and open message is only sent once. So not really sure the full value add here.

4.5 VLAN Forwarding (Yue Wang, 5 mins) [90/90]
draft-wang-pce-vlan-based-traffic-forwarding

• No comments due to time.