# IETF 113 PCE WG Minutes ## PCE Working Group Meeting – Session I #### 12:00-13:00 UTC Monday March 21 Afternoon session * Chairs: Dhruv Dhody, Julien Meuric * Secretary: Hari (Hariharan Ananthakrishnan) * [Slides](https://datatracker.ietf.org/meeting/113/session/pce) * [Video](https://www.youtube.com/watch?v=0B42q75br24) * [Jabber/Chat Logs](https://jabber.ietf.org/jabber/logs/pce/2022-03-21.html) ### 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, 10 min) [25/60] * [Hoamian Zheng] draft-ietf-pce-pcep-stateful-pce-gmpls - it is in my todo list. It is expected to be completed in one or two weeks. * [Dhruv] Hari will be the Shepherd for draft-ietf-pce-vn-association. Thanks Hari! * [Hoamian] This will be handled after the draft-ietf-pce-pcep-stateful-pce-gmpls. ### Stateful #### 2.1 Local Protection Enforcement (Andrew Stone, 10 mins) [35/60] [draft-ietf-pce-local-protection-enforcement-04](https://datatracker.ietf.org/doc/draft-ietf-pce-local-protection-enforcement/) * [Dhruv] Without any hats. We can keep this work as separate entity. If there is a need for doing this for flags, that can be handled as part of PCE optional draft. Interested folks can provide inputs for the PCE optional work. Since PCE optional is an adopted work, it can be updated as part of normal WG process. * [Pavan Beeram] I still would like to see a generalized approach. I have not proposed any text, so I am good with whatever is the current outcome. * [Dhruv] Is it ok if that the enforcement generalization is moved to optional document * [Pavan] I am ok with that. * [Andrew Stone] Its reasonable to handle that in the optional document * [Boris Khasanov] Drafts says about Nokia and Cisco implementations, are the implementations engineering or GA. * [Andrew] speaking for Nokia, implementation is engineering load * [Dhruv] We might have to do a language check. Lets not use of the term "MUST constraint" or "MAY constraint". Is this the best way to describe mandatory field and optional field? * [Andrew] sure will take a look at text to see if we can explain it better. * [Andrew] If that is the last comment that needs to be addresses, is the WG thinks that we can move towards last call over the next year ? * [Dhruv] We should respect the early code point deadline and align this draft for last call accordingly. I will discuss with Julien and prioritize this. #### 2.2 SR-MPLS Entropy Label Position (Quan Xiong, 10 mins ) [45/60] [draft-peng-pce-entropy-label-position-07](https://datatracker.ietf.org/doc/draft-peng-pce-entropy-label-position/) * [Dhruv] Thanks for handling all the comments. Are there any pending issues? * [Quan] No pending comments. * [Dhruv] Julien and I will discuss and get back. #### 2.3 IFIT (Giuseppe Fioccola, 10 mins) [55/60] [draft-chen-pce-pcep-ifit-06](https://datatracker.ietf.org/doc/draft-chen-pce-pcep-ifit/) * [Dhruv] Already in the WG adoption queue. Let me confirm, did we resolve all the pending comments ? * [Giuseppe] Yes, all the comments are resolved. * [Dhruv] Keep the document aligned with other work in other WGs - SPRING, PIM, IDR. * [Giuseppe] Sure, will doable check IDR document to keep them aligned. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ## PCE Working Group Meeting – Session II #### 12:00-13:00 UTC Tuesday March 22 Afternoon session * [Slides](https://datatracker.ietf.org/meeting/113/session/pce) * [Video](https://www.youtube.com/watch?v=bEvqcX1uPI4) * [Jabber/Chat Logs](https://jabber.ietf.org/jabber/logs/pce/2022-03-22.html) ### Segment Routing #### 3.1 Circuit Style Segment Routing Policies (Christian Schmutzer, 10 mins) [10/60] [draft-schmutzer-pce-cs-sr-policy-01](https://datatracker.ietf.org/doc/draft-schmutzer-pce-cs-sr-policy/) * [Haomian] Are you trying to following the kind of bandwidth guarantee in Circuit style only or any additional features? Because of packet switching hardware its hard to achieve circuit style bandwidth characteristics. * [Christian] For each and every link the topology we allocate bandwidth to the path computation element. only SR policies have strict BW guarantee in this circuit style network. any other traffic will not have strict BW guarantee will be mapped to diff-serve links in the queues of lower priority. * [Haomian] I suggest changing term from circuit style to bw guaranteed or something similar. * [John Scudder] presumably you cannot guarantee 50ms unless you bound the latency between A and Z and excluding any midpoint protection. * [Christian] Goal of 50ms was not 100% appropriate. I believe both paths should be established operational in the data plane and once lifeless detected in a path you switch to the other path immediately. * [John] Its the colloquial use of 50 ms means as fast as possible. * [Tarek Saad] Is there an assumption that one PCE managing only SR paths in the network ? Or can they be multiple PCE in the network * [Christian] in the most simple consideration only one PCE is responsible for BW guarantees. The problem with multiple PCE is to get consistency and avoid race conditions. SR policies are somewhat independent from the PCE architecture. * [Tarek] Please clarify in the document. * [Dhruv] There is a WG I-D (PCE state sync) which discusses how multiple PCEs can collaborate. Please have a look. * [Cheng Li] I have done similar thing in CMCC two or three years ago by using path segment. It will be a good chance to collaborate between path segment and this draft. * [Dhruv] In future there could be a use of this signaled in BGP as well. Is this PCEP specific ? Or is this a generic work that could be done in BGP/YANG ? May be we should find SPRING as home for the overall solution. Is this really PCEP specific? * [Christian] I dont think its 100% PCEP specific. We can consider looking into it. * [Dhruv] We are saying we dont want PCE to recompute paths ? They why delegate ? We can use stateless in this case. * [Christian] In the transport world, folks like to have computation done by controller, once it chose it should stay. Thats where the requirement is coming from. * [Dhruv] Lets discuss in the mailing list. * #### 3.2 Circuit Style Policies Extensions (Samuel Sidor, 10 mins) [20/60] [draft-sidor-pce-circuit-style-pcep-extensions-00](https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/) * [Tarak] It seems like you want to lock the path after setup. Why not one-bit to say lock or pin the path ? * [Samuel] We want to introduce higher granularity. Sure, one-bit is sufficient. Both two flags and one flag are possible. * [Andrew] If we are trying to guarantee bandwidth for a given path and there is change in topology, such as a lag member going down. One should expect PCE to tear down the path ? * [Samuel] Even if LSP is down due to topology change, PCE can still trigger the modified path/backup based on LSP going down. May be we can introduce one more flag to say PCE can recompute if LSP is down. * [Andrew] good to introduce 'is path still valid' concept. Good to discuss more in the list. * [Samuel] May be one more flag can be introduced. * [Cheng Li] I see O bit in the PCE object in RFC 5450, can we reuse the existing flag ? * [Samuel] Just for stateful PCE we are introducing new flag. In case of stateless, we are reusing the flags. * [Fan Yang] I see the previous draft is informational draft. There is no extension to the SR policy. This is for previous presenter. * [Samuel] The extension for CS policies is implemented using existing RFCs. There are few changes that we are introducing in this draft. * [Christian] The circuit style SR policy draft is informational because we are not changing the SR Policy architecture. Its about using many different mechanisms using existing extensions. * [Fan Yang] Is this targeted to both SRV6 and SR-MPLS ? * [Christian] That is correct. * [Fan] This work is very interesting work. I think we can confirm more work in other working groups * [Christian] We didnt have lot of time. But we will work with other working groups. * [Dhruv] My initial reaction looking at the TLV was its a Policy and we have policy association that we can reuse. What we need is a way to signal well known policies. What is the best way for us to signal this in long run? Should we define TLVs like this? or should we reuse policy association mechanism. I would like get feedback from authors and WG. Lets take this to the mailing list. ### Others #### 4.1 VLAN-based Traffic Forwarding (Yue Wang, 10 mins) [30/60] [draft-wang-pce-vlan-based-traffic-forwarding-05](https://datatracker.ietf.org/doc/draft-wang-pce-vlan-based-traffic-forwarding/) * [Dhruv] When we did the native IP work in PCE, we had the work in TEAS working group and it was easy to add this extension in the PCE WG. With VCR/VFR data plane tables, I am not comfortable since these are new terms which are not native to PCE. Should these terms be discussed elsewhere so that PCE will just be an extension. * [Yue Wang] We can further discuss in mailing list. * [Aijun Wang] The VCR table is implemented in the device. The main point here is instruction is sent from PCE to PCC. So I think such work should be included in the PCE WG. * [Dhruv] The document is also defining how these VCR/VFR tables are populated and forwarding is happening, I am not sure if that is part of PCE. Let me talk to AD and Julien and get back. * [Aijun Wang] I see these as part of existing mechanism. * [Dhruv] Lets continue in the mailing list. #### 4.2 Multicast Tree Setup (Huanan Li, 10 mins) [40/60] [draft-li-pce-multicast-00](https://datatracker.ietf.org/doc/draft-li-pce-multicast/) * [Dhruv] Lets discuss the comments on the list. #### 4.3 PCECC for BIER (Ran Chen, 10 mins) [50/60] [draft-chen-pce-pcep-extension-pce-controller-bier-03](https://datatracker.ietf.org/doc/draft-chen-pce-pcep-extension-pce-controller-bier/) * [Dhruv] Lets discuss this in the mailing list. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ *Last updated on 25 March 2022 at 0307 UTC*