IETF 125 PCE WG Minutes

Tuesday, March 17th 2026 — Session IV
16:00 - 17:30 (Shenzhen, Grand Ballroom 1)
08:00 - 09:30 (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 mins) [5/90]

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

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

Stateful PCE

2.1 WGLC changes for multi-path (Samuel Sidor, 10 mins) [30/90]
draft-ietf-pce-multipath

• [Dhruv] Thanks for making all of these changes during this final
  review.
• [Adrian] As doc shepherd just to say it's all kind of ready to go
  but waiting for authors to go ahead then finish the cycle then
  recheck the writeup.
• [Dhruv] Perfect.

2.2 Performance Measurements (Rakesh Gandhi, 10 mins) [40/90]
draft-gandhi-pce-pm

• [Andrew] When sending bandwidth or delay information, Is the PCRPT
  the full report? like containing all of the hop and state
  information? Is this going to create an explosion of reports, like,
  receive a state pcRpt and 1ms later receive another report or will
  there be supression? Raising the question of whether we need a
  dedicated message for this since it could be two way. PcUpd today
  can send delay information about the path but don't need to do a
  full heavy path update. The PCE will have to fully process all
  attributes in the report.
• [Rakesh] Good points, can catch up offline.

2.3 Amendment to Stateful PCE (Andrew Stone, 5 mins) [45/90]
draft-many-pce-stateful-amendment

• [Dhruv] Good amount of content to add for the operational side.
• [Andrew] Yeah some of the backwords compatible stuff is
  operationally need to be pointed to. Enforce backup PCE need config
  rules can go at it from that angle.
• [Dhruv] A question for the benefit of everyone even though it
  doesn't solve the problem why it's worth doing. Make it clear why
  this change is better.
• [Andrew] True, can say it's better because no open questions and
  PCC and PCE respect it then nothing special to worry about. Without
  it you don't know and need to do something special and gymnastics in
  proprietary solution.
• [Dhruv] You convinced me want it to be out in open for rest of
  working group.
• [Andrew] Also this doesn't say don't solve it, but that needs new
  work and it's not trivial.
• [Dhruv] To me it's a candidate for adoption and Julien and I will
  take into consideration.

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

• [Li Zhang] Missed the previous discussion, question for the flag
  indicating bsid can be used for computing a path. In RFC 9604 if it
  reports bsid then it can use it to compute a path. So why need a new
  flag here if it can be used for computing a path.
• [Samuel] The PCEP binding SID RFC is being referred to? That's
  specifying if the BSID should be allocated and who should be
  allocating, not whether the binding SID can be used for other
  policies, such as if it's in the middle. My understanding is
  existing just specifies flags to indicate BSID should be allocated
  and who, pce or pcc, not whether it can be used in middle of path
  computation. No flag like that.
• [Dhruv] Samuel would be good to clarify without this T flag you
  can use it / not use - is it only when this flag is enabled am i
  allowed to use it or not. confusion what I'm hearing.
• [Samuel] Basically without this extension the behavior isn't
  modified at all. Trying to introduce explicit behavior.
• [Andrew] To echo Samuel, the BSID RFC is about configuring a BSID
  side, the configuration to the node either to assign or self assign,
  where as this flag is to control whether PCEs are allowed to use it.
• [Samuel] Can clarify it more in the draft.
• [Andrew] Also if you have a lot of BSIDs in the network, can help
  with scale to reduce the search space.

Segment Routing

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

• [Dhruv] Related to liveness, if PCE is involved then its worth
  including. When we do liveness detection we focus within the PCEP to
  focus how everything is running. It's useful but can likely exist in
  another document and be referenced. Can be focused on how the PCEP
  is used in this flow.
• [Hooman] So something such as PCE can see the state of the network
  .
• [Dhruv] Only if that's what it's doing and everything seems to be
  local.
• [Hooman] I'm open what I thought liveness was more about how to
  protect local or end to end tree failure.
• [Dhruv] Completely agree for document on how sr p2mp works, but
  this one focused on pcep extensions. Was hoping this information
  would be in another document and be referenced and how PCEP is
  involved and talk about how things like what happens when no PCE is
  there, like that liveness detection. Mechanisms already there. We do
  features for other like bier and detnet, don't want to focus on
  their liveness but the PCEP part.
• [Zafar] Having a lot of detail regarding FRR in this doc, since
  it's a PCEP version, and anything to do with FRR SR policy p2mp
  should be done elsewhere and clarified elsewhere. Would like to see
  the references used for the link failure for local optimization,
  which is not something pcep is involved with. Having something FRR
  related, description here should be done elsewhere.
• [Dhruv] I also owe you comments and was discussing with Andrew, a
  note to Andrew will respond to that this is next in our WGLC queue.

3.2 SRv6 Inter-layer Network Programming (Minxue Wang, 5 mins)
[60/90]
draft-many-pce-srv6-inter-layer-network-programing

• [Dhruv] Would be useful to tell if i receive this NAI how am I
  using this information. Tunnel ID at the two endpoints but how this
  tunnel ID helps when setting up the path. Explain how one uses it,
  like a figure or description why a new NAI is needed.

3.3 SRv6 Policy SID List Optimization (Zafar Ali, 5 mins) [65/90]

draft-all-pce-srv6-policy-sid-list-optimization

• [Zafar] Will you put this in queue for adoption?
• [Dhruv] Julien and I will discuss, would like more discussion on
  list for sure.

3.4 MSD Consideration (Zafar Ali, 5 mins) [70/90]
draft-ali-pce-sr-policy-msd-consideration

Others

4.1 PCEP-LS Optical (Xiao Li, 5 mins) [75/90]
draft-lee-pce-pcep-ls-optical

• [Zafar] Reservation about this work is BGP-LS already done this,
  so PCEP base got adopted because it was experimental. Have not seen
  any update I recall on the experiment. Running a parallel thing for
  something that has wide deployment of BGP-LS, view of the experiment
  would be useful.
• [Adrian] You're right the PCEP-LS is experimental and still inside
  the WG, this draft is also experimental. Continueing that
  experiment. Maybe we'll see result of optical before packet
  experiments and get a feeling of whether there's success or not. Not
  the intention for PCEP-LS to get wide deployment until results of
  the experiment.
• [Zafar] Is PCEP right vehicle, not clear

4.2 Fine Grain Transport (Liuyan / Minxue, 10 mins) [85/90]
draft-han-pce-fgmtn-setup
draft-han-pce-ls-fgmtn-reporting
draft-han-pce-path-computation-fg-transport

• [Dhruv] This was discussed in CCAMP as well?
• [Fatai] Requirement draft discussed in CCAMP, from chair
  perspective more about PCEP extension so in scope of PCE WG.
  Danielle sent email to chairs to see where it should be. Saw your
  response, and asked authors to explore in other groups. Even for the
  requirement draft still in the scope of PCE
• [Dhruv] Meant we follow the work for what ITU CCAMP set, and
  whether they are ready for us to take on or not
• [Fatai] ITU already did their dataplane work

4.3 Bounded Latency (Quan Xiong, 5 mins) [90/90]
draft-xiong-pce-detnet-bounded-latency

• PCE chairs with discuss with detnet chairs