IETF 114 PCE WG Minutes

• Chairs: Dhruv Dhody, Julien Meuric
• Secretary: Hari (Hariharan Ananthakrishnan)
• Slides
• Video
• Chat-Stream
• Meetecho Recording

PCE Working Group Meeting – Session I

Wednesday, July 27, 2022, 17:30-18:30 UTC

Introduction

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

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

1.3. State of WG I-Ds and next steps (Chairs, 15 min) [30/60]

• [Cheng Li] We do think SR-path-segment and SR-bidir is ready for
  WG LC.
• [Dhruv] Do we think we need to continue with both mechanisms in
  the SR-path-segment draft?
• [Cheng Li] Yes, unless there are comments in the mailing list.
• [Samuel Sidor] I wanted to update on the sid-algo doc. I got
  feedback from multiple sources and there were some conflicting
  opinions. I am trying to consolidate the updates which is causing
  delay. We discussed between the authors and will do partial updates
  and make progress faster.
• [Dhruv] Wherever you are not able to make a conclusion, please add
  an editors note in the document, so that WG can provide inputs.

Segment Routing

2.1 Circuit Style Policies (Samuel Sidor, 10 min) [40/60]

draft-sidor-pce-circuit-style-pcep-extensions-02

• [Adrian] If the path is delegated to PCE, but it is not allowed to
  recompute, why was this delegated to PCE in the first place?
• [Samuel] We still allow PCE to update the path but only if the
  operator explicitly requesting it from the PCE. There is permanent
  flag which means that PCE can still recompute but it will recompute
  only if the original path is invalided.
• [Adrian] You have a use-case that is driving this distinction for
  you?
• [Samuel] the main use-case is still keep the PCE delegation, just
  to make sure that PCE doesn't change the path.
• [Adrian] I hear you. I am not convinced
• [Dhruv] This is the second time this comment has come in. Its best
  to add text in the document.
• [Andrew Stone] PCE is allowed to tear down but not change the path
  that way secondary can take over.
• [Dhruv] We should be careful in what content we put in the SPRING
  doc vs this. In spring doc where things that are PCE specific should
  be moved to this document. SPRING document should not be specific to
  PCE. You or Christian can discuss.
• [Samuel] We can discuss any other separation would make sense.
• [Dhruv] I don't have strong opinion, but I want the WG to be
  thinking about this. Should we think of as this as a policy or well
  know path profile ? Should we do specific TLV/flags as proposed in
  this doc. If this is the direction we are taking, we should be
  cognizant.
• [Andrew] We are trying to describe a policy in the doc, the flags
  are not specific to circuit policy. These could be used for other
  cases.
• [Samuel] If anybody has different opinion we are discussing this
  in the mailing list.

2.2 Redundancy Policy (Fan Yang, 10 min) [50/60]

draft-yang-pce-pcep-redundancy-policy-00

• [Dhruv] The SPRING WG redundancy protection I-D is SRv6 specific.
  We have to make sure SR-MPLS for basic redundancy protection SID is
  also supported.
• [Fan] We can attach this for SR-MPLS and SRv6. I think we can
  discuss and find a better way to fill the blank.
• [Janos Farkas] Coordination with DetNet might be good.
• [Anthony] The Protection Type TLV diagram says 24 bits but the
  diagram represents 32 bits.
• [Dhruv] What is the difference between redundancy protection vs
  protection we already have in PCEP ? How would it work with the
  existing protection if someone specifies both ?
• [Fan] We will come back with more clarification.

2.3 SID Verification (Tan Chen, 10 min) [60/60]

draft-chen-pce-sr-mpls-sid-verification-04

• [Samuel] I want to support the adoption. This draft is introducing
  useful things. There are no other comments from the working group
  for any major modifications.
• [Dhruv] The new wiki page
  https://wiki.ietf.org/group/pce/coordination is still WIP. We need
  to do a better job in coordinating between the documents. Please
  update the wiki, so that we can avoid issues with shared flags.

[Julien] See you tomorrow.

PCE Working Group Meeting – Session II

Thursday, July 28, 2022, 21:30-22:30 UTC

• Slides
• Video
• Chat-Stream
• Meetecho Recording

Stateful PCE

3.1 Operational Clarification (Mike Koldychev, 10 min) [10/60]

draft-koldychev-pce-operational-06

• [John Scudder] Mild preference for option 1 i.e. keep it in single
  draft.
• [Mike] Ok. Sometimes its hard to distinguish between information
  vs standard.
• [Andrew] Operational draft as checkpoint. Since there is some
  update and clarification, I do like option 1. I do believe we should
  adopt this.
• [Dhruv] My preference would be two separate drafts. The separation
  is hard to do. The draft states an update and dives into an example.
  If its single doc, we should find a good way to explain. State the
  normative first and then go on to explain. I will work with authors.
  For an implementer this is easy, for external person this would be
  harder to figure things out.
• [Mike] Sure. In the beginning of the doc we say section x, y and z
  are informational and others are normative.
• [Julien] No one is recommending option - 3. We can ask for
  consensus in WG between option 1 and 2.

3.2 IFIT (Giuseppe Fioccola, 10 min) [20/60]

draft-ietf-pce-pcep-ifit-00

• [Adrian] There was a draft in OPS area WG for IFIT framework. Your
  draft is not making reference to the framework. I wondered if you
  see any relationship or whether it is safe to go ahead without a
  framework document guiding us.
• [Giuseppe] We didn't refer because it was not adopted. May be the
  framework needs to reference this one, since this can be seen as a
  building block of the framework.
• [Dhruv] The term IFIT needs to be clarified. By some mechanism we
  need to solve this. There was one more comment during the adoption
  call regarding the SR-MPLS in scope ?
• [Giuseppe] We can omit SR-MPLS for now. Another thing to track.
• [Dhruv] Having MPLS in scope in important, if we can decide later
  if we need to split into multiple documents later.
• [Giuseppe] We have to follow the discussion there.
• [Dhruv] Since you have draft in IDR, from the start please take
  care of coordination and keep the draft in sync.

DetNet

4.1 DetNet Bounded Latency (Quan Xiong, 10 min) [30/60]

draft-xiong-pce-detnet-bounded-latency-00

• [Janos Farkas] As Dhruv mentioned in the beginning, we are in
  early stage of DetNet. We have lots of solutions in the table. As
  for the information between PCE and devices, the flow info RFC can
  be required. It might be good to wait until the work is more
  matured.
• [Andrew] How PCE learns the processing delay of routers in the
  path? Is there another document ?
• [Quan] The load-delay will be advertised before the path
  computation.
• [Andrew] Its good to clarify that in the document.
• [Lou Berger] In DetNet WG, we still have control plane framework
  document is accepting contributions. If this work informs that or
  any material that they like to add or see covered, it be great to
  bring that in.
• [Dhruv] My suggestion is to have clear requirements from DetNet
  for PCEP and also clear consistent terminology between these various
  solution drafts.

4.2 Enhanced DetNet (Li Zhang, 10 min) [40/60]

draft-zhang-pce-enhanced-detnet-00

• [Dhruv] All the comments given to the previous draft applies to
  this one as well. In DetNet WG draft, there could be multiple BLIs,
  but in PCE we have only one. Thus start with the clear requirements
  from DetNet, that would be helpful in solution development.

Others

5.1 NRP ID (Quan Xiong, 10 min) [50/60]

draft-xiong-pce-nrp-id-01

• [Jie Dong] There is a similar draft called pcep-vtn, which
  includes both the capability part and the LSPA extensions. There are
  currently several control plane drafts (IGP, BGP, PCEP,...) on
  network slicing extensions, the terminology used to be different.
  Since there is some consensus about the network terminology in TEAS,
  coordination among these documents would be needed, and we are open
  to that.
• [Quan] We proposed the draft very early. The difference between
  the VPN plus and NRP:- may be we can discuss offline or in separate
  meeting.
• [Dhruv] Having a single document will be beneficial. I urge the
  authors to work together.

#

Last updated 02 Aug 2022 at 0700 UTC