IETF 126 PCE WG Minutes

Tuesday July 21st 2026, Session IV
16:30 - 18:00 (Vienna, Grand Klimt Hall 2)
14:30 - 16:00 (UTC)

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]

• [Sue] Slide context is P2MP: There is P2MP and an IDR draft for
  that. We'll need to work along cross with spring. IDR draft so when
  we do final call do you want those comments on combinations during
  LC or chair to chair? how to take
• [Dhruv] Discussion would like to have with ADs, right sent of
  coordination of just chairs or WG in place as well
• [Sue] Starting in IDR to put our own rules section where we
  capture details between the WGs and IESG has it infront. Second for
  p2mp there is a parallel track in bess for the multicast, as far as
  I can tell they use the same. I'll make comments on last call
• [Dhruv] The policy we have tsken is we've always waiting on PIM
  and SPRING not all other places
• [Ketan] On that aspect, agree with Dhruv, tech working group for
  lack of better word like SPRING and protocol work done in different
  WG like PCE, IDR. In this matter PCE and IDR are same nature in both
  the expectation is my point as AD is they align with the base more
  like SPRING. Alignment PCE and IDR is welcome as done in both ways,
  but probably more between the authors. My observations same authors.
  So between chairs this is the progress coordinating please do with
  chairs, technical reviews with the WG

Stateful PCE

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

• [Julien] It's good that you move this forward, I like the section
  about overload as it's filling missing peice. Maybe consider missing
  use cases beyond report, upcoming presentation about performance
  monitoring will add some additiona messaging, like we have
  autobandwidth, Perhaps expanded scope
• [Andrew] PM nice change we did is new notification object, but
  there could be something quirky today with PcUp like metric change
  how frequency. Perhaps additional content
• [Dhruv] Just be careful to only clarify and nothing new, balance
  what is there vs already in RFC
• [Andrew] Agreed, focus on interpret
• [Dhruv] We need to see how IESG will interpret this type of
  document. Before LC, Ketan (AD) heads up this is not a usual
  document. This is our way of not changing base spec but some
  implementors found hard time, we want to clarify how it's done. That
  is the attempt with this doc, so need AD buy in
• [Ketan] Full disclosure have not had a chance to read yet, but
  will get to it and give back input

2.2 Stateful Amendment (Andrew Stone, 5 mins) [30/90]
draft-many-pce-stateful-amendment

• [Julien] I like the wording of stateful and stateless bring up,
  and not change what has been there. What I feel is missing is from
  the request, you need a reply. But when you rely on update, you need
  PCE to get the feedback. But PCE implementation may not update, so
  should write something about what. Maybe lower case should, not sure
  best way to address it. Just to make sure clearly describe what is
  changing
• [Andrew] Yeah for example, PcRpt with delegation, compute, no
  path, PCE can stay quiet. So perhaps wording to say PCE may stay
  quiet so PCC should not expect an update
• [Julien] Yes

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

• [Li Zhang] (About capability slide) 3 flags in TLV and last is R
  flag loopback delay measurement. Does it mean round-way dealy or
  something else?
• [Rakesh] Doc discussing how to use stamp, only forward direction,
  two way is pun the packet and timestamp. Loopback is before t1
  timestamp since you don't have timestamp. SRPM describes these
  things but we can add to draft
• [Dhruv] Since im co author will defer to Julien about adoption
• [Julien] WIll poll the room
• [Quan] Reminder not sure if you have mentioned unidirectional
  delay or roundtrip delay. Distingush the two delays and suggest to
  refer to the existing IGP metric for example, advertise IGP metric
  unidirectional link delay then you measure the unidirectional delay,
  to the real delay. To add some reference to the related metric
• [Rakesh] you're right ISIS/OSPF rfcs talk about unidirectional
  delay, but drafts in IPMM like stamp draft that talks about round
  trip delay, many different ways, one way, two way, roundtrip maybe
  we can add some more context about this is also known as this, in
  this RFC. So obvious they are same thing
• [Quan] Makes sense than you
• [Julien] Interest in the room for adoptions, but one no, if that
  person can share why that would be useful and also can send on the
  list. Confirm will be by the mailing list

Segment Routing

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

• [Sue] Perhaps I was not clear in my comments, was raising it for
  administrative seperately, not technically. Now will be technically.
  The current set of drafts are coherent, overall fairly solid. My
  comment has to do with the interaction between various proposed
  drafts we're beginning to see how PCE changes something what happens
  for IDR to change something. Excellent job in the presentation
  saying where IDR work is and where PCE is. As you finish your IDR
  draft if you can put in an appendix which will be removed, will
  speed things. My concern is the tunnel with the use of tunnel encap
  rfc there is your set of work in PCE, which is in BGP with tunnel
  encap, then another in EVPN draft not sure. The one I was concerned
  with is the multicast controller that also uses the tunnel encap in
  bess. We need to look at that, and if that causes a conflict. Two
  things using the same mechanism doing the pretty much as far as I
  can tell, spring general p2mp or something related to it with
  replication segments. Wanted to say it in here because PCE trying to
  do it, how do we detect or say to the operator don't do that. If
  both whether they will be in conflict, somehow have to text that
  says either better be ships in the night not in the same network or
  need to tell me what happens if they do, error handling
• [Hooman] For the draft from bess, think that was by Jeffrey and
  using different route types to download the information
• [Sue] Yes, correct, recently reviewed
• [Hooman] conclusion was that since p2mp policy we use Candidate
  Paths for P2MP policy, we use the similar as unicadt, this is why we
  created the IDR draft which inheriting heavily from the unicast. The
  final conclusion was the draft in bess will yank out the p2mp policy
• [Dhruv] the idea that I got from Sue is that we neec operational
  consideration when we use PCEP, BGP simultaneously.
• [Sue] as dhruv said, should take to bess where I will ask same.
• [Dhruv] Thanks for taking all the comments, main focus was to make
  sure ready for WGLC. Have other comments I will send. One thing to
  bring to the WG, is have a look at appendix especially describing
  the message flow. We get feedback PCEP msg hard to understand, new
  folks struggle. Authors believe representation is something we never
  tried before, want more feedback from the WG is this the best
  picture of message flows we want to do rely on existing ways. We
  should create not one more way of doing things, but brand new
  confusion. Want to get feedback from the group appendix message
  example
• [Zafar] There was some discussion on 4.3.6 on FRR we can talk more
  offline
  [Ketan, from the chat] Thanks for the clarification Sue. You were
  referring to the BESS multicast controller draft. This is between
  IDR and BESS WGs. Not an issue for PCE if this WG is wondering what
  this is about.

3.2 Binding Label/SID Extensions (Samuel Sidor, 5 mins) [55/90]
draft-sidor-pce-binding-label-sid-extensions

Path compute and use cases

4.1 Extensions for Network Resource Partition (NRP) (Jie Dong, 10 mins)
[65/90]
draft-ietf-pce-pcep-nrp

• [Zafar] There is a draft in spring describes data model for
  policies and nrp, and that draft is not referenced by this. and
  there are pending comments in that draft just want to make sure
  aligned. I could be wrong but did not see that, but Jie can see you
  in queue
• [Jie] You mean spring sr policy nrp draft?
• [Zafar] yes, draft ietf spring sr policy nrp
• [Jie] The scope of this PCEP draft is broader and can cover
  general SR-TE and other TE computations, more generic, but can be
  added as informative reference
• [Zafar] Think we can discuss offline but don't think informative
  since data model base is in the spring draft
• [Dhruv] In my reading it's not SR Policy specific, they can carry
  this in LSPA they do it in a more generic fashion. But as
  informative when using with SR polciy, NRP is the best way to handle
• [Zafar] that is fine, just want to make sure its able to address
  SR use case
• [Dhruv] Yes, and NRP drafts have been in IESG lately so maybe see
  those comments
• [Dhruv] right now the terms we use is generic, PCE should consider
  NRP. Need to be a little ibt more specific what computation actually
  means, concrete what it means to be doing path calculation with NRP.
  Only nodes and links belong to the same NRP or not ?? little bit
  more than a should

4.2 Path Delay Difference (Yao Liu, 5 mins) [70/90]
draft-liu-pce-path-delay-difference

• [Andrew] When I read the draft I was confused about uses cases,
  especially multicast. When you optimize about lowest latency you
  need take a specific path, is it better to recieve feeds or better
  to don't receive them. If you will skip that constrain, when what ?
• [Hooman] There is misconcept you cannot optimize the hole tree in
  Multicast. Example, to optimize certain branch of the tree, I doubt
  it, pls double check.
• [Dhruv] Pls pick up the use case that is mostly needed and focus
  on it.

4.3 Extensions for Computing-Aware Traffic Steering (CATS) (Quan Xiong,
10 mins) [80/90]
draft-xf-pce-cats-service

4.4 Precision Availability Metrics (Luis Contreras/Quan Xiong, 5 mins)
[85/90]
draft-contreras-pce-pam

4.5 Implicit TLS in PCEP (Zafar Ali, 5 mins) [90/90]
draft-ali-pce-implicit-tls-profile

• [Dhruv] lets go back and see all the debates, to see why startTls
  or not. what has changed between then and now and we should have a
  good answer to satisfy that.
• [Zafar] no new port, just a different requirement profile.
• [Dhruv] and fair, if we have any protocol in ietf, they would
  think same, we need to think hollistically. Just have to be careful
  to do it and do it right
• [Hooman] only feedback is implemented TLS on radius, usually on
  others, PCEP as great as it is, that first communication to
  negotiate the TLS, the TLS Start is a little bit off like a black
  sheep. No other protocol liek Radius or TACACS, usually these other
  protocol brings up the TCP and when TCP is up first thing is the TLS
  handshake over the port RFC mandates
• [Dhruv] yeah and my understanding is those were TLS from the
  start, and StarTLS was a way to migrate from a protocol that already
  had a clear text version. With the security people when discussed
  back in the day. Talk to the security people early on

If time permits

5.1 PCEP over QUIC (Feng Yang, 5 mins)
draft-yang-pce-pcep-over-quic

• Insufficient time to present

Note: The content below is LLM AI generated from ietfminutes.org, thanks
to Eric Rescorla.

Decisions and Action Items

• Action Item: Andrew Stone to send Ketan Talaulikar (AD) an email
  request to initiate early feedback/review on
  draft-ietf-pce-operational.
• Action Item: Authors of draft-ietf-pce-pcep-nrp to review recent
  IESG comments on other NRP-related documents and refine the
  technical description of "NRP-aware path computation."
• Decision: The chairs will launch a mailing list adoption call for
  the Performance Measurement (PM) draft.

Next Steps

• SR P2MP Policy: WG members are encouraged to review
  draft-ietf-pce-sr-p2mp-policy and provide feedback on the list
  (specifically regarding the appendix's flow diagrams and the FRR
  sections) during the ongoing WGLC.
• Stateful Amendment: Authors will update the Stateful Amendment draft
  to clarify PCE behavior when PC updates are received without a
  preceding request.
• Security Coordination: Authors of the Implicit TLS proposal will
  initiate early discussions with the IETF Security Area to evaluate
  the deployment profile.