# IETF 118 PCE WG Rough Notes {#ietf-118-pce-wg-rough-notes} Thursday, 9 November 2023, Session III, 15:00 - 16:30 CET * Chairs: Dhruv Dhody, Julien Meuric * Secretary: Andrew Stone * Note Taker: Andrew Stone * [Slides][1] * [Video][2] * [Chat-Stream][3] * [Meetecho Recording][4] ### Introduction {#introduction} 1\.1. Administrivia, Agenda Bashing (Chairs, 5 min) \[5/90\] 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\] * Various WG drafts on schedule with dedicated time slots. Few documents are nearing WGLC such as draft-ietf-pce-flexible-grid and draft-ietf-pce-segment-routing-policy-cp. * Authors are requested to contact chairs if their document in adoption queue needs expedited process (with justification). ### Stateful PCE {#stateful-pce} 2\.1 Native-IP (Aijun Wang, 10 min) \[35/90\] [draft-ietf-pce-pcep-extension-native-ip-26][5] * \[Dhruv\] - thanks for update, as shepherd thanks for taking comments into consideration. Want WG to have eyes on the latest changes such as encoding. Tunnel mode - not really sure if it is described well, and whether we should call it "tunnel". What would be the right terminology to use?. I see this still pending. Also suggested to carry error code separately and not add in the status field itself. * \[Aijun\] We will try to add some description for Tunnel Mode in the document. For Error field, will consider it. 2\.2 Stateful Inter-Domain (Julien Meuric/Olivier Dugeon, 5 min) \[40/90\] [draft-ietf-pce-stateful-interdomain-04][6] * \[Dhruv\] - there was discussion in the past about error handling, we parked it because we did not have any of the extensions using it and thought this document would be an ideal use case for it - so please check that. * \[Olivier\] - Yes, will add in and look for in next release as well as implementation section as ODL implementation ongoing. * \[Dhruv\] - awesome to hear. With regards to PCEP going down, such as state sync, any impact with that? Might need more descriptions about things going up, down, etc. Distribute label is clear, cleanup and error handling needs work. * \[Olivier\] - yes, can look at more detail about recover in case of failure. 2\.3 Inter Stateful PCE State Sync (Cheng Li, 5 min) \[45/90\] [draft-ietf-pce-state-sync-05][7] * \[No comments\] ### Segment Routing {#segment-routing} 3\.1 SID Algo (Samuel Sidor, 5 min) \[50/90\] [draft-ietf-pce-sid-algo][8] * \[Dhruv\] - regarding wglc, don't need all code points to do wglc. i.e don't worry to need to do wglc -after- allocation. * \[Samuel\] - and feel free to contact me directly about implementations. 3\.2 SR P2MP Policy (Hooman Bidgoli, 10 min) \[60/90\] [draft-ietf-pce-sr-p2mp-policy-04][9] * \[Adrian\] - wondered about objective functions. Original P2MP PCE defined two objective functions for shortest path and least cost I think, do you see the need for any other objective functions for SR P2MP. * \[Hooman\] - good question, since it's controller focused, think providers will also look at latency too. When it comes to streaming, like mobile video streaming of live shows a lot of delay of video being transferred. I would see latency coming in. * \[Adrian\] - yeah pce can do what it wants for computation, but entity asking to create the path, what type of path does it lead to ask for. * \[Dhruv\] - checked, can use any metric defined. With terminology, borrowing instance id from RFC 3209 seems to be confusing. We need to decide as a WG if we are okay with CP having a concept of path instance inside of the candidate path because in normal p2p we have a Candidate Path with segment list and list of segment. * \[Hooman\] - honestly, memory, going back 2 years when we started this I think the instance we came up, maybe it's incorrect, thought we came up with it as part of the tree instance itself. * \[Dhruv\] - we have it everywhere so if this instance is right term or not. * \[Hooman\] - way we identify the tree is root id, tree id and the instance * \[Dhruv\] - yep, fine with design, just the term * \[Hooman\] - gotcha * \[Dhruv\] - when we talk about slicing, need to be careful. In PCEP let's talk about flex algo, MT etc. * \[Cheng li\] - I read it but found it complicated. Do we have any implementation of this now? * \[Hooman\] - up to now implementation have been cli but now PCEP is ongoing to try and get an implementation. * \[Cheng li\] - recommend add implementation status. * \[Hooman\] - we will add the implementation section before WGLC. ### Others {#others} 4\.1 PCEPS update for TLS 1.3 (Sean Turner, 10 min) \[70/90\] [draft-ietf-pce-pceps-tls13-01][10] * \[Sean\] - doc changed quite a bit, should we do another WGLC? * \[Adrian\] - decision to do another WGLC will leave to chairs, I just wanted to say thank you for doing the security work and coming here with this. * \[Julien\] - no harm for another WGLC. * \[Sean\] - it's (doc) ready to go in data tracker already. 4\.2 Fine-grain Transport Network (Liyuan Han, 10 min) \[80/90\] [draft-han-pce-path-computation-fg-transport-00][11] * \[Julien\] - thank you for presentation. As far as I understood there's a new dataplane specified in ITU-T, how much of this work has been discussed with CCAMP? Whatever we do here, need to do in coordination with CCAMP. Any plan with CCAMP? Any schedule or draft? * \[Liyuan\] - for this meeting we also requested timeslot with CCAMP but no available time. Draft has been sent to that WG. * \[Julien\] - encourage you to trigger discussions with CCAMP. * \[Liyuan\] - okay will continue on to discuss with CCAMP. 4\.3 Precision Availability Metrics (Luis M. Contreras, 10 min)\[90/90\] [draft-contreras-pce-pam-00][12] * \[Samuel\] - about metric type extension, isn't it fixed length? * \[Julien\] - yes it is, so it can't be the one as it is as 5440. It would need to be new code point * \[Dhruv\] - i understand we define a new object type. I think best to have a generic extended metric object type with various tlvs. So we solve this in one go. * \[Dhruv\] - another thought, I haven't read PPM draft, but use cases from SR Policy or similar in PCE context would be better. Where would we see and use this? It provides some insights what metric can be useful. * \[Luis\] - yep sure will work on adding that * \[Olivier\] - goal is to cover a close loop system? Why do you need this interval ratio and threshold and why not directly recompute a path incase of eelay constraints are not met. For example, original request, if path is asking for <20ms delay, if at a certain moment parameters change, path exceeds it, decide to recompute. Why do you need this ratio and interval etc and not trigger path computation immediately * \[Luis\] - good question, point is to take into account historical behavior. If we keep historical how it was behaving, then we can check that. Recompute incase of problems could also be checked. Selecting or picking the path based on historical observed. In otherwords, two different paths with same metric right now might have different historical behavior. I can choose from the more adequate path based on the history. [1]: https://datatracker.ietf.org/meeting/118/session/pce [2]: https://www.youtube.com/watch?v=dKxQ65FAJNw&ab_channel=IETF-InternetEngineeringTaskForce [3]: https://zulip.ietf.org/login/#narrow/stream/pce [4]: https://www.meetecho.com/ietf118/recordings#PCE [5]: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ [6]: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-interdomain/ [7]: https://datatracker.ietf.org/doc/draft-ietf-pce-state-sync/ [8]: https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/ [9]: https://datatracker.ietf.org/doc/draft-ietf-pce-sr-p2mp-policy/ [10]: https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/ [11]: https://datatracker.ietf.org/doc/draft-han-pce-path-computation-fg-transport/ [12]: https://datatracker.ietf.org/doc/draft-contreras-pce-pam/ --- *Modified by Dhruv Dhody on 16 Nov 2023 1021 IST*