# IETF 114 PCE WG Minutes {#ietf-114-pce-wg-minutes} * Chairs: Dhruv Dhody, Julien Meuric * Secretary: Hari (Hariharan Ananthakrishnan) * [Slides][1] * [Video][2] * [Chat-Stream][3] * [Meetecho Recording][4] ## PCE Working Group Meeting – Session I {#pce-working-group-meeting--session-i} ##### Wednesday, July 27, 2022, 17:30-18:30 UTC {#wednesday-july-27-2022-1730-1830-utc} ### Introduction {#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 {#segment-routing} 2\.1 Circuit Style Policies (Samuel Sidor, 10 min) \[40/60\] [draft-sidor-pce-circuit-style-pcep-extensions-02][5] * \[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][6] * \[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][7] * \[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 {#pce-working-group-meeting--session-ii} ##### Thursday, July 28, 2022, 21:30-22:30 UTC {#thursday-july-28-2022-2130-2230-utc} * [Slides][1] * [Video][8] * [Chat-Stream][9] * [Meetecho Recording][10] ### Stateful PCE {#stateful-pce} 3\.1 Operational Clarification (Mike Koldychev, 10 min) \[10/60\] [draft-koldychev-pce-operational-06][11] * \[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][12] * \[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 {#detnet} 4\.1 DetNet Bounded Latency (Quan Xiong, 10 min) \[30/60\] [draft-xiong-pce-detnet-bounded-latency-00][13] * \[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][14] * \[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 {#others} 5\.1 NRP ID (Quan Xiong, 10 min) \[50/60\] [draft-xiong-pce-nrp-id-01][15] * \[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* [1]: https://datatracker.ietf.org/meeting/114/session/pce [2]: https://www.youtube.com/watch?v=8CJNyGNFjC4 [3]: https://zulip.ietf.org/#narrow/stream/253-pce/topic/jabber/near/26586 [4]: https://play.conf.meetecho.com/Playout/?session=IETF114-PCE-20220727-1730 [5]: https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/ [6]: https://datatracker.ietf.org/doc/draft-yang-pce-pcep-redundancy-policy/ [7]: https://datatracker.ietf.org/doc/draft-chen-pce-sr-mpls-sid-verification/ [8]: https://www.youtube.com/watch?v=nU78N-uebIc [9]: https://zulip.ietf.org/#narrow/stream/253-pce/topic/jabber/near/31781 [10]: https://play.conf.meetecho.com/Playout/?session=IETF114-PCE-20220728-2130 [11]: https://datatracker.ietf.org/doc/draft-koldychev-pce-operational/ [12]: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-ifit/ [13]: https://datatracker.ietf.org/doc/draft-xiong-pce-detnet-bounded-latency/ [14]: https://datatracker.ietf.org/doc/draft-zhang-pce-enhanced-detnet/ [15]: https://datatracker.ietf.org/doc/draft-xiong-pce-nrp-id/