IETF 122 PCE WG Minutes

Monday, 17th March 2025, Session IV
17:00 - 18:30 (Bangkok, Chitlada 2)
10:00 - 11:30 (UTC)

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

Introduction

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

[Chair] - Thanks John and Welcome Ketan

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

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

Segment Routing and Stateful PCE

2.1 SRv6 Policy SID List Optimization (Zafar Ali, 10 mins) [35/90]
draft-all-pce-srv6-policy-sid-list-optimization

[Andrew] - Echoing that we had a conversation just about an hour ago, relaying to the group. The document right now reads really PCE-Init oriented, and the MSD section, thanks for adding, would be good to clarify if only for PCE-Initiated or also consider what it looks like if PCC-Initiated. It could be valuable for MSD, to inform PCE for PCC-Initiated you have one more SID under some circumstances. It might be good to compare PCC-Init/PCE-Init.
[Zafar] - Thanks for the comment and offline discussion, yes, agree we can add coverage for PCC-Initiated policies
[Dhruv] - There was also a comment about a common document in SPRING, it exists in IDR and in PCE, any plans about a common document in spring to define this
[Zafar] - Yes a comment from Bruno, SPRING chair, during the last IDR session, and the action item is for authors to talk with Bruno and to look for guidance from PCE and IDR chairs about the right thing to do. If they say yes, then we'll take that route.
[Andrew] - The PCC-init side a bit unique to cover in SPRING, the behaviour of PCC-init isn't often discussed in SPRING, whereas PCE-Init and BGP share some similarities for the controller push-down but the PCC-init side is a bit unique
[Dhruv] - SPRING is the right place to talk in a more more neutral terms and the extensions can come in PCE

2.2 Stateful Interdomain (Olivier Dugeon, 10 mins) [45/90]
draft-ietf-pce-stateful-interdomain

[Andrew] - On the notify function—specifically, whether it can be summarized as the PCC/PCE (i.e., the PCEP speaker) requesting a resignal or recalculation of a delegated LSP.
[Olivier] - the proposed notification message is between PCEs, it’s feasible that a PCC could also trigger such a notification. For example, via PCInitiate or a PCRpt indicating a path down or transitioning to a down state. The notification message could potentially have broader applicability beyond the specific interdomain use case.
[Andrew] - Thanks, was thinking operationally if an operator wants to kick the LSP they can't do it on the PCC and have to go to PCE to do it, as opposed to on the PCC could trigger that refresh. Might be operationally some value.
[Dhruv] - I think what they defined is targetted specific stateful interdomain, but could be good to consider other generalized cases as well.
[Dhruv] - Thank you for making progress and addressing the comments, but, we need more reviews as the document is getting more complex with the various procedures (BRPC/HPCE/SRv6..). Any volunteers to review? Boris and Oscar in the room volunteered, thank you so much and we need more reviews!
[Dhruv] - Regarding naming, since we like to debate naming, any thoughts anyone? I think changing from the stitching label might make sense. Any thoughts?
[Andrew] - I agree with changing from the stitching label because of SRv6, but, since the draft had an RSVP solution in there, I'm not sure if binding SID would be appropriate, I also don't have a concrete name to suggest
[Boris] - I vote for binding sid it's more common
[Samuel] - I vote for binding SID as well for simplicity
[Adrian] - Slightly flippant but what about path key? I say that having not read for a very long time, but it seems like the concept is to put some kind of identifier that expands to the next piece of path. Maybe we already have that?
[Dhruv] - Something to think about. Authors, perhaps start a thread and get more eyeballs to start with naming to get a bigger discussion.
[Dhruv] - Regarding association, are we worried about the scaling impact of that for every path to get a new association group created?
[Olivier] - Yes, you need it per-path because the association group gives a reference to the end-to-end path for this interdomain path. Each PCE has a local reference for this end-to-end association. The goal is not to provide an interdomain path for the whole internet and thus scaling is acceptable.
[Dhruv] - Suggestion to handle it - add a scalability section to cover this aspect as well. We currently have both H-PCE and BRBC mechanisms, are both in active use currently? It would be good to get more feedback from operators on what is actually being deployed.
[Olivier] - Okay
[Zafar] - One comment on the last question - not following it closely but if the concept is also an identifier for the forwarding then binding sid is the best match

2.3 Topology Filter (Quan Xiong, 10 mins) [55/90]
draft-xpbs-pce-topology-filter

[Samuel] - One question about the domain identifier, I see multiple fields there, how does the filter work? Do I need to set all the fields or some of them are considered loose filters? (Reference to topology-filter object slide) should I set all of them (Properties in the TLV) always?
[Dhruv] - Yes I agree, sub-tlvs would be better for extension as in future if there is a new field it is easier to add it as a sub-TLV
[Samuel] - Yes, like if the Algorithm is always zero don't need to always include Algo 0
[Zafar] - Trying to understand the overlap of this with constraints. Let's say NRP is a constraint and PCE does topology filtering to compute a path based on constraints - it’s unclear if these mechanisms seem parallel! Additionally, fields like provider ID and client ID need clearer definitions, as their roles are not well understood.
[Quan] - We will clarify the relationship between the existing constraints. It is more about the general topology constraints and will cover all kinds of topologies including NRP, flex-algo and so on. The TLVs are optional and filtering rules are mandatory.
[Dhruv] - What we need to clarify is how it works with other constraints. We have those relax flags, that could be one way for us to consider what is mandatory vs optional. Even with the TLVs, clarify if only one is used at a time. Using all of them would be too complicated.
[Zafar] - Yes those kinds of details would be good to include like how the overlaps happen
[Andrew] - +1 to Samuels's comment, optional sub-tlvs. For example, ISIS instance IGP instance filter wouldn't need OSPF area ID

2.4 PCE Operational Clarification & Amendments to Stateful PCEP (Andrew Stone, 10 mins) [65/90]
draft-koldychev-pce-operational
draft-many-pce-stateful-amendment

[Dhruv] - Thanks for taking over and helping out. It has useful content and it's been there in the adoption queue for a long time and as we said earlier, we could prioritize it. We will be sending an adoption request for pce-operational.
[Andrew] - Do think operational is information and clarification, so hope it will move faster than amendment since it's not updating things.
[Julien] - Thanks also for clarifying there is consensus among implementers on this.
[Adrian] - I like the operational document but don't imagine it would ever be an RFC, it's more of a continuing catalogue, adopted draft or a wiki page whichever is best to go with that. Having the WG behind it is a nice idea.
[Dhruv] - Adoption is key at this moment, but whether we publish or keep it in a living document the WG can decide
[Andrew] - I agree there's still eventual new stuff but feel the content is a good snapshot of what we have today, if we have to snapshot in the future we can do that again.

2.5 LSP State Reporting Extensions (Samuel Sidor, 10 mins) [75/90]
draft-sidor-pce-lsp-state-reporting-extensions

[Dhruv] - When it was last presented there was discussion about strict v/s loose path about explicit, but that comment was not addressed in the document. Any thoughts on that?
[Samuel] - Addressing comments still pending
[Dhruv] - Thanks for making an update on other comments
[Boris] - What's the point of D flag when LSP is instantiated when it will be kept down
[Samuel] - Allows LSP to be created, but headend will retry. Will be allowed later, ex: conflict between two BSID. Headend can retry and bring it up. Conflict is resolved LSP will go up and PCE does not need to retry.
[Boris] - Got it, thank you

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

[Zafar] - Question and comment - I'm not too intimate with PAM but when I last reviewed it a device can invalidate a candidate path but not something that becomes a path compute aspect or optimization. I think we really need to understand whether these attributes truly compute or are just something that can be used to invalidate a candidate path if it does not meet the criteria.
[Luis] - Basically it would be devices reporting metrics (telemetry). Some components characterise the links based on statistical behaviour and PCE can use that as the base for selecting the path. So we can have a notion of stability. Understanding the latency, for example, has been maintained based on the histogram. We want a slice to behave 99.99% of the time below a threshold so we can ensure the path we will compute will respect that value.
[Zafar] - Think we need more discussion, for example, a link with delay doesn't change like this or if it's the queueing and a different discussion. Another question is are you carrying these attributes in IGP?
[Luis] - The reporting of the metrics as is today. But the metrics reported and some collector has the history of how the links behaved. Would not change anything on the device.
[Zafar] - Let's have the discussion offline.
[Dhruv] - I think the confusion in PCE metrics are constraints, as computed values, different use of the same object. Is precision only for one specific purpose? Should be clarified to avoid confusion. Should be more explicit on the interaction between the precision metric object and the metric object - if delay is mentioned in both, how will that interact?

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

[Dhruv] - Just clarification, the shepherd review is not yet done, Andrew can clarify.
[Andrew] - I went through the document with the shepherd writeup in mind and sent some feedback to Hooman on it, that was basically taken into the new update but the writeup hasn't taken place yet, to kind of early prep the document.
[Dhruv] - Process point of view, we do WGLC first, then the shepherd review, then the writeup, so we assigned the shepherd early to help with the process early
[Andrew] - Yeah it was either the last or previous IETF that was asked to help shepherd this so tried to help out there
[Dhruv] - Would be good to share with list
[Andrew] - Well the feedback I gave wasn't a shepherd review it was just some cleanup to the document and purely editorial. Technically nothing has changed it's just wording and structure and sentences updated. Actual shepherd hasn't happened yet
[Ketan] - Please for the WG, please keep an eye out on PIM-SR-P2MP with Gunter to see if nothing missing in this document
[Dhruv] - We'll be looking for volunteers to review this document too, especially any of those with multicast. Any volunteers?
[Hooman] - On that note, I asked last IETF if there's ongoing implementations, so please send feedback sooner.