# IETF 116 PCE WG Minutes Monday, 27 March 2023 15:30-17:00 Japan time (06:30-08:00 UTC) G401-G402 (4th Floor) * Chairs: Dhruv Dhody, Julien Meuric * Secretary: Hari (Hariharan Ananthakrishnan) * Note Taker: Hari * Thank you soo much!!! * [Slides](https://datatracker.ietf.org/meeting/116/session/pce) * [Video](https://www.youtube.com/watch?v=72c-j-Er-TU) * [Chat-Stream](https://zulip.ietf.org/#narrow/stream/pce) * [Meetecho Recording](https://www.meetecho.com/ietf116/recordings/#PCE) ### 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] * [Pavan]: Regarding draft-rajagopalan-pce-pcep-color. We have not formally requested early code point yet. We will send an email out. ### Segment Routing 2.1 Open issues in SID Algo (Samuel Sidor, 10 min) [35/90] [draft-ietf-pce-sid-algo-00](https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-00.html) * [Dhruv]: I would suggest we do this in two steps. In the first step ask the working group if anyone has concerns with using Flex Algo as possible way for us to use FAD (constraints). Instead of focussing on how to do, as a working group we need to agree that this is something we want to do. Based on the input from mailing list, most folks agreed that this is what we wanted to do. * [Shaofu Peng] Using content of the FAD for path computation as an alternate option compared to using existing LSPA, metric object or policy group.The FAD constraints is more suitable when logic of path computation is better represented by FAD and have subtle difference in existing PCEP objects. * [Dhruv] Would you mind sending this to list? * [Stephane] When you insert Flex Algo in SID list, we cannot ignore the FAD. FAD will drive the IGP Point of view, the sub path within the end-to-end path which is associated to this particular Flex Algo. You have no way to ensure that the IGP is following what you are expecting. * [Dhruv] I thought its optional (even in the proposed solution). We want to make it an option whether we should consider FAD constraints or just give me a path with this SIDs of this algo ID only? * [Stephane] We still have to consider FAD at some point. * [Dhruv] I misunderstand what you mean by consider FAD? * [Stephane] It is implementation dependent. * [Dhruv] Consider FAD or give me a path with SIDs belonging this Algo ID. * [Stephane] Which is possible. When we insert the SID, IGP will following the FAD anyway. * [Samuel] My understanding is use cases where one of them can have limited PCE implementation where only SID filtering is needed. * [Stephane] It is a very limited use case. If you consider FAD which has IGP Metric you cannot say its Flex Algo. Its just the best effort IGP routing. Attributes of the link need to come from ASLA. * [Samuel] Agree that it is a small use case to filter out topology. * [Dhruv] Keep the comments to this point in the queue. * [Andrew Stone] I see the usage of FAD as valuable. Please find the path with all the special capabilities you have also consider FAD 1.9. Leveraging the constraint as part of Flex Algo is useful. * [Dhruv] Clarifying question. Usefulness is established. Is there a case of not consider FAD. Has anything changed since we adopted it. * [Andrew] There are use cases where PCE wants to program SIDs. In the original request at adoption it was filtering SID selection and now we invoke underlying TE based on the FAD definition and enforce it. * [Zafar Ali] There is an issue and clear from the problem statement. * [Dhruv] Suggestions to authors is lets break it down a bit, work offline. Stephane and I will form a question to the WG. What are the two sets of requirments. Lets focus on requirement and not the solution. We are debating about the previous requirement now and there is support and no objections to handling FAD constraints. 2.2 PCEP SRv6 Extension (Cheng Li, 7 min) [42/90] [draft-ietf-pce-segment-routing-ipv6-16](https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-16.html) * [Dhruv]: Please use the face to face time to resolve WGLC comments. * [Cheng] We can address the comments offline. 2.3 SR Policy (Mike Koldychev, 5 min) [47/90] [draft-ietf-pce-segment-routing-policy-cp-09](https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-09.html) * [Dhruv]: To WG, there are two questions for me. First, is this document the right place to document this? RFC 8664 says how to carry SR path (no mention of SR Policy), where RRO is used RSVP-TE or SR. Whatever clarification we do, it should be outside of SR policy architecture. Then we can discuss the validatity of the statement 'PCEP speakers SHOULD NOT send the RRO'. * [Pavan] SHOULD NOT seem bit extreme. RRO carried actual path. If you have an LSP up and running, locally controlled and trying to delegate, implementations tend to include the current path in RRO. * [Mike] In the RSVP-TE LSP, RRO is optional. * [Pavan] There are lots of TE features dependent on RRO. Even though its perceived to be optional. * [Mike] In Cisco, by default RSPV-TE does not use RRO. * [Pavan] In some implementations, the key functionality would not work without RRO. * [Pavan] SHOULD NOT is bit extreme. MAY is fine. * [Mike] RRO is optional. RSVP-TE LSP that never uses RRO. How can the LSP actual path be conveyed by RRO when RRO itself is optional. * [Pavan] 95% RSVP-TE deployments rely on RRO (Ex. Bypass). For SR policies, LSP up and running, locally controlled and try to delegate, we do need RRO to delegate. We could do IRO, but IRO is not an ordered list. You need a way to convery the actual path and saying SHOULD NOT is extreme. * [KaZhang] PCE calculate the path and download the path with ERO. May be ERO is in the format of interface address or node address but not as Segment ID. In this case, head end of the SR policy may translate the address to the segment id. In this case, how can we report the real path is different from ERO and how to report to the controller. * [Mike] You report back in the same ERO. * [Dhruv] That would be breaking the existing RFCs. * [Adrian] I have soo many issues with this slide. Obviously RRO has no meaning in SR Policy architecture because it does not talk about signalling. However there is difference between the SR path that is initially imposed on a packet vs SR Path traversed by the packet. There may be SID substitutions or SID expansion. There is a concept in the SR policy architectuer of the actual path. There is no way to convey the actual path in SR policy architecture. That is orthogoal to whether the concept exist. There is value in RRO for SR. "PCEP speaker SHOULD NOT send the object for SR policy", here SHOULD NOT embraces MAY requires that we specify what it means when it happens. I think you either use MUST NOT or actually define what it means. The thread that Dhruv and I had on the list of about EROs/RROs. The WG needs to step sideways and talk about EROs/RROs in PCEP. Get that nailed down and we can push this forward much more quickly. * [Mike] We need to think about what RRO means in SR context. I feel that you should not say that RRO is the actual path. In the RSVP-TE world, its completely optional. * [Dhruv] Lets continue in the mailing list. Do you want to block the document based on this discussion? My suggestion is that this is beyond SR policy because we have RFC 8664 on sr path. In PCEP, we published the RFC before the SR Policy architecture. We allow an SR Path to exist without an SR Policy. We can obsolete that if the WG wants but we need to respect it till then. 2.4 P2MP SR Policy (Hooman Bidgoli, 7 min) [54/90] [draft-ietf-pce-sr-p2mp-policy-03](https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-policy-03.html) * [Dhruv]: Request you to review RBNF from existing document. P2MP policy is not an object. Regarding RBNF, we have kept it backward compatable. What we currently see on the slides, is not going to compile. * [Hooman] Message received. Learning curve is steep. 2.5 Circuit Style Policies (Samuel Sidor, 5 min) [59/90] [draft-sidor-pce-circuit-style-pcep-extensions-03](https://www.ietf.org/archive/id/draft-sidor-pce-circuit-style-pcep-extensions-03.html) * [Dhruv]: Any feedback from SPRING WG that you like to share ? * [Samual] There were no major updates to the draft. * [Zafar Ali] The construct is generic and use case is common. ### Stateful PCE 3.1 BFD (Sasha/Marina, 7 min) [66/90] [draft-fizgeer-pce-pcep-bfd-parameters-00](https://www.ietf.org/archive/id/draft-fizgeer-pce-pcep-bfd-parameters-00.html) * [KaZhang]: sBFD is used only in the headend. It may not need to negotiate BFD parameters with the controller. We can reuse the ASSOC object, we can compute the BFD parameters on the headend, and list ASSOC ID in the PCEP message. There will be many parameters if we extend it this way. The controller need not know the BFP paramaters. * [Dhruv] Send this to the mailing list. This was discussed earlier. Search on the archive list and start the discussion. * [Andrew Stone] I like this work in the context of reporting state. Like the TLV format. Thanks for the work. * [Dhruv] Which other WG we should notify about BFD? * [John] Yes, BFD WG. MPLS would not hurt to notify. 3.2 NRP (Jie Dong, 7 min) [73/90] [draft-dong-pce-pcep-nrp-00](https://www.ietf.org/archive/id/draft-dong-pce-pcep-nrp-00.html) * [Dhruv]: One simple suggestion would be to mark that this document replaces other two documents in the datatracker. * [Jie] We will need your help. ### Others 4.1 Updates for PCEPS (Sean Turner, 7 min) [80/90] [draft-dhody-pce-pceps-tls13-02](https://www.ietf.org/archive/id/draft-dhody-pce-pceps-tls13-02.html) * [Adrian] This is great. I hope the wG can flip it through. * [Sean] This is a short draft 6 para * [Adrian] if I am a PCEP implementor and I wanted to run PCEP over TLS 1.3. Could I just pick a public stack? Are there implementations around ? * [Sean] Its widely available. There are multiple stacks that supports. * [Dhruv] I am one of the co-authors. I will let Julien to take the chair go ahead. Reminder it is also related to PCEP-YANG and good if this I-D is adopted when the YANG goes to the IESG. * [Julien] Can you request a show hands? * [Dhruv] Poll initiated - good support, will be confirmed on the list! 4.2 BIER-TE (Ran Chen, 5 min) [85/90] [draft-chen-pce-bier-10](https://datatracker.ietf.org/doc/html/draft-chen-pce-bier-10) * [Dhruv]: Any feedback from BIER WG that you would like to share ? * [Ran] We received feedback from Juniper. our draft only focus on BIER-TE, we will change the name to reflect it. * [Dhruv] I will take the AI to talk to BIER chairs. 4.3 DetNet Bounded Latency (Quan Xiong, 5 min) [90/90] [draft-xiong-pce-detnet-bounded-latency-01](https://www.ietf.org/archive/id/draft-xiong-pce-detnet-bounded-latency-01.html) * [Dhruv]: We have to take this to the mailing list. Apologies for going over by 6 mins! --- *Last updated by Dhruv on 2nd April 2023 1213 IST*