IETF 120 PCE WG Minutes
Thursday, 25 July 2024, Session III
15:00 - 16:30 (Vancouver, Regency A/B)
22:00 - 23:30 (UTC)
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]
- [Cheng] Thanks for the help on the drafts. We will have a new RFC 9603 which is about PCEP SRv6 extension. Will follow up the rest of documents with priority, this may take some time.
- [Dhruv] Thanks Cheng
- [Andrew] (Regarding draft-dhody-pce-iana-update) A blanket to change the registries sounds good to me. For the handful of registries where theres little number of bits we'll still be able to block it and require a formal extension to make sure the bits get extended.
Segment Routing
2.1 Carrying SR Algorithm (Samuel Sidor, 10 mins) [35/90]
draft-ietf-pce-sid-algo
- [Dhruv] Did we have a chance to discuss with LSR authors to get a review, especially update about the bandwidth thing
- [Samuel] I don't think any discussion happened, least I'm aware
- [Dhruv] Yeah think it would be good to CC LSR WG on this. I've also asked for early review from routing directorate and opsdir so we can move this forward
- [Samuel] Great, thank you
2.2 SR P2MP Policy (Hooman Bidgoli, 10 mins) [45/90]
draft-ietf-pce-sr-p2mp-policy
- [Dhruv] You already have comments, early allocations will start with the updates. Prior to the meeting start we had a discussion and think it would be good to have someone familiar with the way PCE documents flow, especially in the context of RBNF. If anyone has any concerns I've asked if Andrew would be shephard on this so if anyone has any concerns of this please bring up
- [Boris via chat] - no concerns
Stateful PCE
3.1 PCE Controlled ID Space (Cheng Li, 15 mins) [60/90]
draft-ietf-pce-controlled-id-space
Note: For reference below discussion, slide presentation had Option 1 is PcOpen only(existing document), Option 2 is for using PCEP-LS, Option 6 is for PcOpen+PcNotify
- [Zafar] Are we doing the right thing? It's most suitable to do it from management plane. Looks like feature creeping in PCEP. Now that we're working and handling this, seem not design for such things. Best to solve this problem through the management plane.
- [Dhruv] We said most implementation would consider this ID space as static. How true/often that is unclear. Should only add new blocks, since change/remove can have widescale impact so reset might be needed. There was a concern about size of open message, if too many distributed blocks, size of open becomes an issue, wanted to understand more from group on this topic. The 6th option can take care of it, that maybe you can cover the size issue with open plus notification. Cons of open could be removed with Open+Notification. Can live with (option) 6. Prefer option 2, seems like the right thing to do so it's a property of a LS node. Each node basically gives their label blocks controlled by PCE. Cheng said that would tie it to much but it doesn't mean you need to implement the whole thing and just LS report and only advertise mandatory TLVs. From implementation not too much effort, but concerned about the fate between the two since LS is experimental
- [Samuel] Still prefer option 6 but I can imagine if some implementations does not need to change the range, then they can combine with some capability so even option 1 can be used. So anyone implementing knows they can still with just open msg. They can implement the notification on top of that later.
- [Andrew] Samuel said what I was also thinking about saying. Nice thing is embedded in open, it's used for a lot of nodal specific info. If you do want to manipulate without reset, notification can be bolted on top. In terms of feature scope, do think idea of changing values given in open without session flap does have value. See this as an opportunity to cover that gap, as other use cases might need that. See that as taking concept of open, and generically solve open by using notification. If your PCC doesn't support it, then no need to implement notification.
- [Adrian] Like way Andrew presented that however let's not use this draft to shoe-horning we want to do this for other things. Did we identify a need to update this specific peice of information on the fly? We don't have to rule it out but if no identified need, start with open the look at the bigger space and suck this in as an update if needed.
- [Andrew] Yeah totally agreed, we could say this doesn't solve it and we'll solve independently
- [Dhruv] Any ideas on what else needs to update in open msg?
- [Andrew] Would need to go back and look
- [Diego via audience] MSD is one
- [Andrew] Yes, MSD is a good example. MSD chassis value may need tuning and can save flapping PCEP session
- [Dhruv] Yep, so Cheng option 1, not much update anymore and we'll solve notification in future. We should take to list of course, seems we want to solve in generic way outside this document. Anyone interested to start working on that document.
Summary from discussion it might be a better approach to say this document will not solving the update-open message but to solve that generic problem as an independent draft. To be taken to the list
3.2 State Sync (Cheng Li/Dhruv Dhody, 10 mins) [70/90]
draft-ietf-pce-state-sync
- [Andrew] Tieing back to the previous presentation this is another good example of carrying open content in PCNtf. While the identifiers will be different it shares a common pattern of open messge content refresh is carried via notification, in this document it's relaying information of a sub pcc whereas in the prior presentation it's direct
- [Dhruv] We can confirm this is way forward, suggest authors update document and Adrians comment and lets move it forward
Others
4.1 Optical extension for PCEP-LS (Haomian Zheng/Yang Zhao, 10 mins) [80/90]
draft-lee-pce-pcep-ls-optical
- [Dhruv] Have you already sent msg to CCAMP or something plan to do ?
- [Haomian] Yes, trying to help with this. G.709 is next significant topic we're going to work on. There is applicability check ongoing in CCAMP WG. In that document, this document will be mentioned. Not a formal email
- [Dhruv] To confirm the TLV types here are defined somewhere else right?
- [Haomian] Current version encoding is based on existing RFCs.
4.2 Precision Availability Metrics (Luis M. Contreras, 10 mins) [90/90]
draft-contreras-pce-pam
- [Zafar] On the requirement - you mention about the selection of path calculation using these metrics. In IGP your topology has transmission information. You can do stuff like delay bound, but this is a metric for computation at the device like SLA style for the policy. I do agree with the corrective action, but the calculation struggling with. Even if you have the info, if you compute, and trigger happens moving to next path, even for triggering there is an obstacle but for path calculation a bigger challenge
- [Luis] We were discussing how this can be done due to the mathematical calculations and the assumptions. How feasible to address the first case. For second and third not much issues. Need to understand feasibility of the first.
- [Zafar] Also having this on a link basis at the PCE, that's the only way can do the calculation.
- [Luis] This info could not doing the collection, but PCE can access elsewhere providing the information
- [Zafar] When triggering going to the next candidate path, theres drafts in spring talking about invaliding a candidate path. So this could be a metric added amongst those criteria
- [Luis] Would be great if you can send the pointers to those drafts
- [Dhruv] From last time would like to understand a bit better from your why a new object is required, as opposed to new object type which has the precision of of the type. Ie. type 2 is precision
- [Luis] What i can do is send to the list a pro and cons analysis
- [Rakesh] To add to Zafar, for link delay, goal is to measure the fiber length and that remains fixed. Here it's availability, how many packets violated. It's more for services, but for link its fixed. Not clear to me how this fixes with PCE
- [Luis] Also take into consideration queueing time.
- [Rakesh] Do you mean to say when you know the SID List you keep end to end statistics, and when PCE gives path, it says this is not suitable for my serv ice.
- [Luis] Yes
Last updated by Dhruv on 30th July 2024 at 0925 IST