Session Date/Time: 17 Mar 2026 08:00
00:13 Dhruv Dhody: Julian, should we start?
00:20 Julien Meuric: Yes, we can start.
00:23 Dhruv Dhody: I’ll pass the slide control to you.
00:28 Julien Meuric: Okay. Thanks. Working well. So, hello everyone. Good morning, good afternoon, wherever you may be on the globe. This is the PCE working group session, live from Shenzhen.
00:51 Julien Meuric: So, the usual "Note Well." I hope you're familiar with the fact that anything you may say during the working group session is subject to IPR rules. There are a couple of IETF policies related to IPR. Some references are listed here. So, in case you have any doubt, please refer to those documents or ask the chairs or AD, Ketan is in the room as well. So, make sure that you are fully aligned with the IETF policy about the intellectual property rights when you come on and attend IETF sessions.
01:36 Julien Meuric: So, the session is recorded. The session is broadcasted online, and people are joining from various places, including myself. So, to make sure everything will work friendly, or work properly, there is a queue mechanism. You may join the queue using either the full heavy Meetecho client or the light one, especially for your mobile phone. Join the queue and Dhruv and I will manage the floor with respect to the queue at the mic.
02:12 Julien Meuric: Remote participants, in case you aren't talking, make sure your mic is off. We can mute you, I think, but make sure you have the right to speak before taking the floor. We highly recommend a headset, especially for people who will present, because usually that's the best way to achieve a decent sound quality. Reminder to keep in mind to state your name when you start to raise a question. This will be particularly helpful for the minutes.
02:52 Julien Meuric: So, about the minutes. Andy, Andrew Stone, is on the bridge. So as usual, taking minutes to give him a hand. Here's the link. You may use it, especially to make sure he properly reflects what you've been trying to say during the session, and make sure your name is properly spelled and so on. Feel free to give him a hand. So we've already spoken about the queue. And as you know as well, there is a chat available either directly from the Meetecho client or using the Zulip tool if you prefer to.
03:41 Julien Meuric: Usual reminder about the working group work. Make sure you actually use the list. So over the past few weeks, I think the traffic on the list has been decent, but we would like to see working group participants be more vocal during critical states, especially during working group last call, working group adoption of new work and so on. We really need to be able to judge about the consensus on a given topic to progress any document within the IETF. So Dhruv and I really appreciate when people share their views and thoughts using the mailing list. And especially as well, contributors of documents, feel free also to use the mailing list or to CC the mailing list when you have significant progress on the document. It shows us how alive the documents are, what the progress is, where the issues may raise, and where the working group may have views to share with the working group document editors.
04:52 Julien Meuric: A couple of things here. One to the working group wiki, where you'll be able to witness the queues we have for working group adoption and working group last call. The GitHub. We don't have that much work on GitHub in the PCE working group, but that remains a useful tool for various working groups within the IETF, so it's good to try to make use of it as much as possible. And a reminder about code point, early code point allocation, that we will tackle a bit later during this introduction.
05:31 Julien Meuric: So here is the agenda. So as usual, a stateful related session, a segment routing focused session, and the miscellaneous session at the end. So unless anyone has anything to bash, or any comment to share, you'll witness that this is a tight agenda. So if you are a presenter, try to respect your time schedule and time frame.
06:06 Julien Meuric: So, about the working group documents. We don't have any new RFC since the previous IETF, but three IDs are currently in the editor queue. So almost cooked, to be published in the near future. One of them is related to the multi-path document, which is progressing on its side as well. So the third one will be unlocked when the multi-path document will be available. No blocking issue there, just delay. And we have one another ID which is in the hands of the IESG, related to the circuit style extension in PCEP. So the approval announcement has been sent already, so it's progressing quite well.
06:56 Julien Meuric: So, we have the draft-ietf-pce-multipath document. So the working group last call was extended before the IETF. I think the official date is already behind us. So I think it's ready to move forward. It already has some early allocation of code points. So we are quite confident that it will be okay, as Ketan reminded us a couple of times ago, some time ago. In any case, the registry won't free the allocated code points, so it leaves us some time to publish the document and make sure the code points early allocated will be finally associated to this specification.
07:47 Julien Meuric: The bidirectional segment routing extension also has some early allocation and the document is with the RFC editors, so no issue there. The circuit style is already with the IESG. IANA is aware that the document is progressing, so even if the deadline may be reached, we're in a situation where we don't have any concern about the outgoing result about the code point management here. So we're quite good. And the draft-ietf-pce-sr-p2mp-policy SR policy. The code points were already renewed a couple of times. So it would be nice to progress the document before this summer.
08:44 Julien Meuric: Other documents. So we have the usual liaisons with the ITU-T about their work plan. And we may be involved in any response to the ITU-T about the work in progress in the Path Computation Element working group. So usual polite communication with the ITU-T on our topics. No issue for the PCE working group at this stage.
09:20 Julien Meuric: So, we move to the status of the IDs. Do you want to take the floor there, Dhruv?
09:24 Dhruv Dhody: Yes. Thank you.
09:27 Julien Meuric: You're welcome.
09:30 Dhruv Dhody: Yes, so let's quickly talk over some of the working group IDs and how the open issues and next step. Any of the authors or editors of these documents, if they want to add a little bit more information, please use this time to do that. The first thing that we have is the draft-ietf-pce-state-sync document. These are the documents that have passed working group last call, but they have not yet been sent to the AD. We had a little change in the shepherd for the state sync document. We have Andrew now who's going to shepherd. Andrew has promised to do the shepherd review after the IETF meeting. And then moment that is done, we will be progressing this to our AD.
10:14 Dhruv Dhody: With draft-ietf-pce-flexible-grid document, we had an update, but there is still one pending comment when we were checking. And Huaimo, if you want to add more information, please.
10:23 Huaimo Chen: Yes, I confirmed Andrew's comments in working group last call are still pending and we will publish an update soon.
10:31 Dhruv Dhody: Yeah. Once that is done, I think we have the shepherd review already done. Shepherd review is already handled, so only one pending thing and then we can most likely send this to the AD.
10:41 Huaimo Chen: Yeah. Yes.
10:42 Dhruv Dhody: Perfect. For the document about draft-ietf-pce-pcep-extension-pce-controller-sr PCECC segment routing, this one completed the working group last call. We have Yisong who has joined us as a shepherd, and we are just waiting for the shepherd review to happen and then we can send this. So one message: if folks are interested in document shepherding, please come to chairs and volunteer. This is a good way to learn what happens with the document once the document leaves the working group and how it progresses at the IESG.
11:17 Dhruv Dhody: These are the set of documents which are next in an audit queue. So we have three items which are in order. We have already done the working group last call for draft-ietf-pce-multipath multipath. Adrian has been—has done his shepherd work and document has made multiple changes. That's why it's on the agenda. And after discussion in this meeting, we will most likely close this and then send this to the AD.
11:44 Dhruv Dhody: After this, we have draft-ietf-pce-sr-p2mp-policy P2MP policy, which Andrew is shepherding and we will do the working group last call for this document. This document is also on the agenda. So if people have early comments, now is the perfect time to do that. And after this, we have put draft-ietf-pce-pcep-ls PCEP-LS, which is an experimental document, up in an audit queue.
12:03 Dhruv Dhody: The rest of the items are unordered. So if there is any feedback that you have on which document we should progress next, please reach out to chairs and tell why it needs to be priority. "It is my document, it is my favorite document" doesn't really help. Give us reasons like, "Oh, I have an implementation pending," or "I need a particular reason why we should prioritize this." Otherwise, we will try to progress them at the time they entered our queue in the same order. That will be our default, but we are free to change things based on the inputs that we receive.
12:35 Dhruv Dhody: So bunch of documents which are in the queue. After this, draft-ietf-pce-pcep-ifit IFIT, draft-ietf-pce-stateful-pce-autobw-update auto bandwidth, draft-ietf-pce-entropy-label-position entropy. All of these documents claim they are ready, but we have been highlighting they are still missing important things like implementation section or operational sections. So please, please handle this. Don't wait for last moment to do that. Especially there has been lot of discussion on doing operational section correctly. So and this is important. Try to handle this early, not as the last step. Otherwise, it doesn't help why we are doing this. We want to handle operational consideration while we are developing the protocol extension itself.
13:17 Dhruv Dhody: Some documents which are, according to us, nearing working group last call. One is the draft-ietf-pce-sr-path-segment path segment one. This is making good progress in SPRING. So but it—we have normative dependency to that, and we are just following up with moment the things happen up in SPRING, we will do the same in—in PCE.
13:38 Dhruv Dhody: Then these are some other working group IDs. Some are also expired as has been noted. Some people in the past promised to do reviews which are still pending. So we are reminding Boris and Oscar. Yeah, you promised us reviews on inter-domain draft, which is still pending. Please do that. We need to review each other's work, especially working group documents. That's how we make progress.
14:01 Dhruv Dhody: Few more IDs. As you can see, we have a lot of adopted work. So we need support from the working group to do the reviews. That's how we will more progress. Otherwise, this queue will be a little longer. Okay, that's it. I don't want to take more times, but people have any concern, please use this time or any other status with respect to their working group documents that they want to share with the working group. Please feel free. Otherwise, let's get on with our agenda. Thank you.
14:52 Julien Meuric: So the first presenter should be Samuel, right?
14:55 Dhruv Dhody: Yes. Welcome, Samuel. And Samuel, you should have the slide control.
15:02 Samuel Sidor: Yeah. I have. Thanks a lot. Hi, all. Samuel Sidor from Cisco. This presentation is about 2.1 WGLC changes for multi-path support in PCEP on behalf of authors.
15:15 Samuel Sidor: So at first, few words about why the draft is useful. So existing PCEP drafts and RFCs are allowing encoding of single segment list per candidate path, which is not sufficient for more complex use cases and for modern traffic engineering. One of them is support for ECMP or load balancing across multiple—multiple segment lists. Second use case is about path computation for SR policy with higher bandwidth value, which cannot be easily satisfied by single path. For example, because of the limited bandwidth available on specific interfaces. So the bandwidth of the multiple interfaces needs to be combined to satisfy the original requirement of the policy. Third use case is about signaling one or more forward and—and reverse segment lists for the SR policy, which is required for concepts like circuit style SR-TE policy.
16:19 Samuel Sidor: So how we solved it? So we introduced PATH-ATTRIB object, which is used for encoding of path specific identifier, some flags indicating operational state, directional of the segment list, whether it is forward or reverse segment list, and multiple optional TLVs. I will not go over all—all of them one by one, but we have dedicated TLV for encoding of the segment list weight, for the backup segment list association, which was required for the point-to-multipoint protection use case. We have the opposite direction TLV for encoding association between the forward and reverse segment list. We have the forward class TLV, which was needed for specific use case of the composite candidate path for per-flow policy. For handling backward compatibility, we introduced dedicated capabilities to make sure that each implementation can advertise support for some of these TLVs. Not all of them—not all of them needs to be supported by each implementation. In the capability TLV, we are also advertising number of supported segment lists, so it can be negotiated between the PCEP peers. So PCC can indicate that it can support, let's say, five segment lists, PCE up to 10, and the lower of those is used.
17:48 Samuel Sidor: Now for the summary of changes which happened since last IETF. So there were multiple versions submitted since then. So based on the comments received, we made multiple changes in multiple sections. Terminology section was extended. So we made it explicit that the PCE must not compute more—more paths than what was negotiated between the PCC and PCE. Multipath capability TLV can be included in both open mess—open object and the LSP object. And the clarification was done what it means when the TLV is included by the PCC or PCE in each of those.
18:32 Samuel Sidor: Then RBNF for the stateful PCEP messages was updated, since the original—original one included in the previous version was not too strict and was allowing inclusion of multiple EROs even without the PATH-ATTRIB object, so without using the separator between them. So we—we made it more strict now and we are allowing two options: either a single ERO or multiple EROs but always separated by the PATH-ATTRIB object. And the original version of the draft was not updating RBNF for the PCInitiate message, so we added it now as well.
19:15 Samuel Sidor: Then for the—for the multipath backup TLV, we explicitly specified that point-to-point is out of scope of the draft, and we explicitly clarified that the backup path IDs must match path IDs in same LSP. And new error message was introduced if—if the TLV is used for the point-to-point path. For opposite direction TLV, we split the text into—into two separate sections. Originally whole description of the—of the TLV was part of the section 3.5. Now we split it into two parts: so protocol extension and the—and the processing or the operation subsection. So it is consistent with—with the structure of the other TLVs. And then we introduced some clarifications or some description for the link and node protecting flag. We explicitly specified that the path IDs between the forward and reverse segment list must match, and we fixed the—the typo for the TLV length, which was there on some place.
20:36 Samuel Sidor: So I hope that all the comments were addressed. If any of them was not addressed, please let me know, but I tried to cover all of them. So the—the—for the next steps, the draft is stable. It is implemented by multiple vendors. So the only thing which I can see as pending is the—the closure on the discussion about number of authors, which is still kind of in progress. Thanks a lot for all the comments received and any—any discussion is welcome.
21:15 Dhruv Dhody: Thank you, Samuel, for presenting all these changes that we have made in the working group last call process and during the shepherd review and everything. This is very good progress that you have made. And we have our document shepherd for the document coming to the mic. Hi, Adrian.
21:31 Adrian Farrel: Yeah. Adrian Farrel, as document shepherd. Just to say, it's all kind of ready to go, but I'm waiting for the authors to finish the cycle and then I will do a re-check of the draft and then a re-check of the shepherd write-up and then kick the chairs.
21:48 Dhruv Dhody: Perfect. You can kick us anytime. Any other questions? Are everybody happy with the changes that are being made? Any concerns? Hearing nothing. Thank you, Samuel.
22:04 Samuel Sidor: Thank you. Thanks a lot for listening.
22:08 Dhruv Dhody: Next up we have Rakesh.
22:28 Rakesh Gandhi: Good afternoon, everyone. My name is Rakesh Gandhi from Cisco Systems. I'm presenting the 2.2 Performance Measurements draft on PCEP extensions for PM for SR-TE and MPLS-TE LSPs with stateful PCE on behalf of my co-authors listed here. So this draft has been around for a while. It was TE LSP and now recently we updated to include the SR-TE LSPs and hence we are here presenting the draft.
23:02 Rakesh Gandhi: So we'll look at the agenda, the requirement and scope of the draft, overview of the procedure, bunch of PCEP extensions, and the next steps. So requirement is to monitor the SR-TE as well as MPLS-TE LSPs. This is end-to-end LSP monitoring for delay, loss, liveness. And then it's a proactive monitoring before carrying traffic or reactive if threshold is violated. For example, then stateful PCE can compute path to avoid degraded that violated the SLAs, for example. There is also use case for reporting real-time bandwidth if you want to implement auto-bandwidth on the stateful PCE. As mentioned the scope is the PCE and PCC initiated LSPs for both SR-TE and MPLS-TE. What's not in scope is the how the measurement's done, which protocol is used, what PCE does with the measurements, or the streaming telemetry use cases for visualizations and NMS kind of stuff. That's not in scope.
24:22 Rakesh Gandhi: So if you look at a very big picture, just a kind of repetition of it, that the focus is in-scope PCE and PCC with the PCEP extensions for PM, either enabling PM on the LSPs or monitoring and basically computing alternate path when path is degraded. What's not in scope is all the telemetry where network analytics, planning, prediction, visualization, all of the YANG telemetry is not in this scope.
24:54 Rakesh Gandhi: So if you double click a bit more on it, when we talk about PM here, we are talking about LSP end-to-end measurements and not about the path computation using the link matrix. That's already been around for some time now. So if you double click on what are the PCEP extensions we're looking at for LSPs, obviously measurement capability come into the picture. Measurement attributes you want to enable the measurement and specify some parameters for it. And when there are threshold crossings or what's happening with the measurement, you may want to report it to PCE so it can find a different path, for example.
25:39 Rakesh Gandhi: So going more into details of various protocol extensions, I may not go into each and every bits and pieces, but idea is that you have a capability for the delay measurement, loss measurement, liveness detection, bandwidth utilization, one-way, two-way, loopback, various modes for each of them. Similarly, in terms of attributes, you want to enable the feature: delay, loss, liveness. You have transmit interval for the packets, what protocol to use, various report thresholds, as well as intervals. And not all TLVs are applicable to all of the cases. For example, you don't have measurement protocol for bandwidth utilization.
26:28 Rakesh Gandhi: And then we have extensions for reporting the values. So delay measurement, you may want to report one-way, two-way, loopback delay values. Similarly for loss, you want to report how many packets were lost, or received and sent, as well as for liveness: if the state is up, or it's down, or there is an error. And the bandwidth samples if you're implementing auto-bandwidth on the PCE.
26:56 Rakesh Gandhi: So this is applicable to Samuel just presented the multipath and this applies to the multipath for SR-TE as well. And there is always this overwhelm state if you have very high scale and doing lots of measurements. Be careful, but there is overwhelm state notification.
27:21 Rakesh Gandhi: So we welcome your comments and suggestions. We want to know, do you think this is useful functionality to have? And if yes, then let's work on it together as a working group document. Thank you.
27:43 Dhruv Dhody: Andrew. Thank you, Rakesh.
27:48 Andrew Stone: Hey. Can you guys hear me okay?
27:51 Julien Meuric: Yeah. We can hear you.
27:52 Andrew Stone: Um, yes. So I—I'm guilty of not reading the document thoroughly, so apologies for that. I was just wondering the messages with let's say bandwidth and delay, the PC report messages are going to be the entire record, correct? Including all of the hop information?
28:06 Rakesh Gandhi: No. So it's I think they are in sub-TLV format, so only needed sub-TLVs are included and not all of it.
28:17 Andrew Stone: So you would expect a PC report, for example, a regular PC report today could carry all the hop information. Whereas for these messages, you would say, okay, the hop information would be omitted?
28:27 Rakesh Gandhi: Yeah. It's just what's enabled, that get reported and those are sub-TLVs, so not everything would be there.
28:35 Dhruv Dhody: I—I think Andrew's asking what happens to the rest of the report message? Because report message has so many other objects and everything. That remains to be—that you need to keep sending them. Am I correct?
28:47 Andrew Stone: Yeah. I—I guess I'm basically just worried that so take PC today, it's getting reports from the network. You're going to get reports now that contain the statistics information. Do those records also contain information about the state of the LSP? Like, for example, is it de-duplicated on the PCC when the PCC sends it? Or not? Or are you going to get potentially, you know, you're going to get a hop information status update and one millisecond later, you're going to get a statistics update? So I guess I'm looking at it from two angles: could we get an explosion of PC report messages? And then vice versa, could we get an explosion of PC report messages and we have to process the PC report message in full every single time? And by in full, I mean evaluate the hop instructions, evaluate the operational state, evaluate basically all attributes of the PC report today.
29:37 Rakesh Gandhi: Yes. That's correct. And I think you're alluding to this one, right? So yeah, you would have all, yes.
29:46 Andrew Stone: Because I—I like that there was a PC notify to kind of say, "Hey, I'm overloaded." But even that takes time to push down. And so I was actually debating prior to this, just at a high level, if there's actually a use for an alternative report message, right? Not a path state report message, but an alternative message of informational. And so I'll give you an example. Even today, if you send down a PC update, right? You can carry the delay information in a PC update. If that latency—if that delay changes, today you have to send a very formal PC update, get an acknowledgment back with a report, as opposed to some kind of essentially notification that says, "Hey, for this—for this LSP, these are the newest statistics information." And so from that perspective, that's PC to PCC. That could still be valuable in the PCC to PCE perspective. So it might really be worth evaluating here if this actually justifies requiring a new message.
30:46 Rakesh Gandhi: Yeah. It's a good idea, Andrew, and let's connect offline to double click on it. And yeah, but I like the idea.
30:54 Andrew Stone: Sounds good. Thanks.
30:55 Rakesh Gandhi: Thanks, Andrew.
31:00 Julien Meuric: Thank you, Andrew. Very interesting question. Any other feedback from the working group? Okay. I think we're done with this one. So thank you, Rakesh.
31:21 Julien Meuric: And I think the next presenter will be Andrew.
31:26 Andrew Stone: Yes. Get to hear my voice again. Okay. I'm bringing up your slide. Andrew, do you have the slide control? Looks like it. Yep.
31:45 Andrew Stone: Okay. So hello everybody. I'm going to be just kind of giving an update to the 2.3 Amendment to Stateful PCE document on behalf of the co-authors. Basically, this document presented back in IETF 123. It actually goes back quite a while. Uh, I think it went back like four or five years now if you really look at the original content. And so this was forked out of the operational clarification document. And there was really kind of two major categories in it. One was it introduced this concept of stateful LSP bring-up, essentially skip a PC report. And the second one was to discourage the use of RRO, or recorded route object, for segment routing. So that's the original content. That was already presented. That's been pretty static for multiple years now.
32:29 Andrew Stone: What is new now in the new version 3 is there's actually a brand new section related to orphan LSPs without delegation. So at the last IETF, this was actually raised by Marina and, you know, thank you very much Marina for raising this, that essentially there's a gap in RFC 8281. Basically, if you have a delegated PCE, and that delegated PCE dies, well, the RFC says that two things can happen. For that specific LSP, either the PCC can give the delegation to a backup PCE, or the backup PCE can request the delegation. But it doesn't actually say how does the backup PCE know when to do that or when it should take the action. And so some implementations will just automatically give delegation to a backup PCE. In other cases where the PCC expects a backup PCE to come take the delegation back, there becomes a challenge there. And so there's some workarounds apparently on some implementations that involve timers. Um, essentially there's nothing standardized in how should the backup PCE know when to actually take this action? You know, how do you know that an LSP has become orphan without delegation? And then of course there is some questions there about what does it look like if you have more than two PCEs, right? Are they going to fight over which one should request delegation? Is there race conditions and timing and whatnot? So that problem space was raised by Marina. Again, thank you Marina for bringing that. There was a discussion at the last IETF. And so as part of an offline email exchange, we basically said, "You know what? Let's at least comment on this topic inside the stateful amendment document just because we are making updates to stateful PCE."
34:10 Andrew Stone: So the proposal is actually to not solve anything right now. Um, at least in this document, right? Nothing precludes any future documents from describing a better solution or proposing different new encodings, new messaging, whatever. At the moment, this update really just acknowledges there is a problem here, there's a gap, and so to discourage that problem, so that way, you know, implementers and interop doesn't have issues, the old text that was in RFC 8231 is essentially being updated to say, "You must attempt to redelegate." So you completely avoid the orphan problem by having the PCC redelegate back to a backup PCE. So that text from the old to the new, you can see went from a "may attempt to redelegate" to "must attempt to redelegate." And then of course, there's some other text in there that's related to, you know, um, what does this mean for backward compatibility?
35:01 Andrew Stone: And so yeah, so the next steps. Obviously, I think the document's pretty—you know, it's got some decent content in it. We don't want to balloon this to try to cover every possible update or every possible tweak. It does have a couple of key things that are obviously valuable to anybody implementing stateful PCE. So looking for working group adoption. And then there is still the manageability sections and security sections to fill out. To be honest, I don't have a clear view on what should go in there at the moment, but obviously we'll have to massage some ideas in there soon. And I think that's everything. So thanks.
35:38 Dhruv Dhody: At least for the operational section, this is important because there's already deployments. So how do we change things and how would that impact? I think there is a good amount of content to add especially from the operational side.
35:52 Andrew Stone: Yeah. And so even the latest update tries to cover some of the backward compatibility discussions to point out some of these changes aren't—are backward compatible or some of them are not, right? Very explicitly, like—um, so there is those discussion points. I think operationally we'll have to definitely point to those other sections. Um, in terms of more kind of, you know, what does it mean to not signal certain things or do signal certain things. Well, obviously the backup PCE, you know, to enforce that you have to have configuration rules and so on. But I think we can kind of go about those—that angle so far.
36:24 Dhruv Dhody: Andrew, one question maybe for the benefit of everyone. If we go to the previous slide, maybe you could also explain that even though this doesn't solve the problem, why is this still worth doing?
36:38 Andrew Stone: In terms of worth doing as an implementation or worth doing as part of the document?
36:42 Dhruv Dhody: No, asking this change that PCC must attempt, because it's there is still wiggle room there. We say there is still local policy, there is still this thing. So just so that we are all clear that this change is definitely better and that's why you're making it. But maybe we need to be explicit why this change is better.
36:58 Andrew Stone: Yeah. True. Uh, I can just say at least it is better because you're not going to have any open questions. So if both the PCC and the PCE respect this change, well, then you don't have anything special to worry about. Whereas if you don't do this, it's kind of—well, you don't know. Somebody's going to have to configure something on the PCC that says, "Hey, you shouldn't expect to receive delegation." And if you have mixed deployment, you know, some PCCs respect redelegating, some of them don't, again, the PCE doesn't know when it needs to do stuff. So there's going to have to be some other gymnastics there that essentially take place in a non-proprietary—non-open standard way and more of a proprietary solution.
37:48 Andrew Stone: Yeah. Thanks. Thanks, Andrew. I—you convinced me. I wanted it to be out in the open and rest of the group also should be able to think about it, whether it's a good idea or not. Yeah. And again, this doesn't say, you know, don't solve this problem, don't allow PCE to do, you know, grabbing delegation. It's just that needs new work. And that work is not going to be trivial or obvious right off the bat. So it's easier to at least acknowledge the problem and kind of discourage it for now until somebody would fix it.
38:09 Dhruv Dhody: Thank you, Andrew. Any other feedback from anyone? Thank you. I think to me, it is a candidate for adoption for sure. And we will—Julian and I will definitely take that into consideration. Thanks.
38:25 Andrew Stone: Cool. Thanks.
38:37 Julien Meuric: Next we have Samuel.
38:45 Samuel Sidor: Hi all. It's Samuel Sidor from Cisco again. So this presentation is about 2.4 LSP State Reporting extensions in PCEP, and I'll be presenting it on behalf of authors which you can see listed in initial slide.
39:04 Samuel Sidor: So for the problem which we are trying to solve and actual solution, there are two gaps which we are trying to address by this draft, both by introducing new flags in LSP-EXTENDED-FLAG-TLV. So the first gap is covered by the X-flag. The problem is that when PCE is receiving the LSP delegation for PC-initiated LSP, it cannot easily derive whether the path—the original path was explicitly specified by the operator when the provisioning was done of the PC-initiated LSP, or it was computed dynamically. And then what can be—what can be the result is that the PCE will modify or recompute the path which was explicitly requested by the operator, which is not intended. So the X-flag was introduced to indicate the source of the original path, so whether it is operator-specified or it was dynamically computed. The second gap is covered by the Transit Eligible flag. So in PCEP, there was no standard way to discover which binding labels or which binding SIDs of which PCEP LSPs can be used as a transit SID in the segment list of other policies. So if the T-flag is set for the LSP, it indicates that the binding SID may be used in the—in the path computation for the other policies. We have also dedicated capabilities for each of those flags to—to cover the backward compatibility.
40:44 Samuel Sidor: So just short summary of the—of the changes which happened since last presentation which was done in IETF 123. So we made few changes. We clarified the difference between the—between the X-flag and the strict and loose path hops. So where the X-flag is the path level attribute, and it is indicating who specified the path originally, so whether it is coming from the operator or it was—it is coming from the dynamic path computation. While the strict or loose is the hop level attribute, so the operator can still strictly specify to go to R2 via specific link and then loosely to let's say R4 via any other link—or via any link, so it is basically loose path. But the X-flag can be still set to indicate that it was explicitly requested by the operator. On the other hand, there is also option that the PCE is computing the path using strict hops only. So basically all the hops are strict, but the X-flag is still set to zero because the path is computed dynamically.
42:00 Samuel Sidor: There were multiple other small changes done. So we specified the backward compatibility handling, for example what should happen if the flags are set if capability was not advertised. Clarification was done for the multiple segment list, that the X-flag is LSP or the candidate path specific attribute, so it is not allowed to mix dynamic and explicit paths inside of the single CP. We added the examples for both extensions, including some diagrams to—to indicate what's the actual use case and—and where the extensions are needed. And we expanded the security considerations and terminology sections with some clarifications.
42:47 Samuel Sidor: So for the next steps, any comments, any discussion is welcome. Since those changes which were done since last—since the IETF 123 are minor and the draft is stable, we would like to ask for the adoption. Thanks a lot for listening.
43:08 Dhruv Dhody: Thank you, Samuel. Any question for Samuel? Li Zhang, yeah.
43:11 Li Zhang: Sorry for mis—missing the previous discussion. I want to just ask a question for the flag indicating whether the BSID is can be used for computing a path. Because as defined in RFC 9603 and 9604, if a PCC reports a BSID to the PCE, then it means the PCE can use this BSID to compute a path. So why we need a new flag here to indicate whether it can be used for computing a path?
44:03 Samuel Sidor: At least I'm not aware about such existing flag. So the RFC which you refer to is the PCEP RFC?
44:06 Dhruv Dhody: Yes. That's the one. 9603 is that one.
44:18 Samuel Sidor: Yeah, but that's just specifying whether the—whether the BC should be allocated and who should allocate the binding SID. At least based on what I recall properly. So it is not specifying—here what we are—the T-flag is specifying is whether that—that binding SID can be used for the path computation for the other—other policy. So in the segment list of the other policy, you can include the binding SID, let's say in the middle, to—to make the computed segment list shorter. But my understanding is that the existing binding SID RFC is just specifying the flags which are indicating whether the binding SID should be allocated and who should allocate that binding SID. So whether the—whether the binding SID is allocated by PCE or PCC, but not whether the binding SID can be used in the middle of the path computation—so there is no explicit flag like that.
45:21 Li Zhang: Okay. Thank you.
45:22 Dhruv Dhody: Samuel, it would be good to clarify in the way that without this flag, right now we don't say anything, that means you can use it, you can not use it. Everything's allowed. Now when this comes in, does it—this also mean that only when this flag is enabled, then I will be able to use it? I think that might be the confusion what I'm hearing.
45:43 Samuel Sidor: Yeah. Yeah. So that's—basically without these—without this extension, the—the behavior is undefined at all. I agree. So finally what we are trying to introduce here is explicit behavior. But we can make it clear in the draft.
45:57 Dhruv Dhody: Andrew.
46:01 Andrew Stone: Yeah. I was just going to echo what Samuel was saying. The existing RFC basically gets the configuration down to the actual PCC to say, "Here's how I want to configure a BSID, whether or not it's self-assigned or I-assigned, I want to configure the BSID." Now that it's been configured, are PCEs allowed to use that binding SID? Because I might have provided that binding SID for a special reason, it doesn't necessarily mean that I want anybody to start blindly using it. And so it's just kind of a way to kind of say, "Hey PCE, you're free to use this binding SID as you choose. It's here, it's—it's something you can tap into, but in other cases with this flag, you basically say no, don't use this. I'm using it for a specific reason." The—the other thing to consider as well is just from a scaling and performance. If you have a lot of binding SIDs in the network, that's also a lot of information for PCE to track and potentially use. And so by explicitly saying, "Hey, this is a binding SID here, but you shouldn't use it as part of your computation," that actually reduces, you know, the data space and the search space and so on.
47:21 Samuel Sidor: Well, we can still—we can still clarify that in the draft as well to make it clear, if not already done, because I—I remember that we—we added some clarification about the backward compatibility, but we can make it clear.
47:48 Dhruv Dhody: Yeah. The—the other thing to consider as well is just from a scaling and performance. If you have a lot of binding SIDs in the network, that's also a lot of information for PCE to track and potentially use. And so by explicitly saying, "Hey, this is a binding SID here, but you shouldn't use it as part of your computation," that actually reduces, you know, the data space and the search space and so on. Yeah, thanks.
47:24 Samuel Sidor: Thank you.
47:25 Julien Meuric: Thank you. Any other questions? No. Let's move to the next. So we have done with our stateful segment and now we are moving to segment routing. And the first one we have is Hooman.
47:53 Hooman Bidgoli: Thank you. So we did get some comments on this draft. I really appreciate the comments. I tried to put them into the draft. Have a read and—and let me know what you think. So just to give a little bit of update: the first two, well, the first draft which was the draft-ietf-pce-bier-te replication, that's already RFC. The next two drafts, one for the actual draft-ietf-pce-sr-p2mp-policy SR P2MP policy, it's still in the editorial queue. The second one, which is the ping, is also still in the editorial queue. The MVPN EVPN is done with the comments, so it is going into the editorial queue. So there is a good flow here, and obviously the PCEP is the next one that we are looking forward to.
48:42 Hooman Bidgoli: So what did we change in the version 14? We fixed a bunch of nits. Thank you for the comments again. The names are there. And we updated the operational consideration. There is a very good point that when it comes to a point-to-multipoint policy, if you are building a entire tree through the network, every single router has to be connected to the PCEP. So there is a scaling consideration here, and that's one thing we put in into the operational consideration, that the scaling of this solution might go beyond the unicast source routing. That's only thing I put in there. I couldn't think of anything else.
49:27 Hooman Bidgoli: And the next one was the liveness detection. So there are two main ways of figuring out the liveness for this solution. Number one is that we use the draft for the ping extension for point-to-multipoint SR policy. As that that draft is done, you can actually use the ping or the trace route through the tree from the root all the way to the leaf routers to figure out if there is a break in your tree. And if there is a break, you can go to the next candidate path that you have built on the head-end, or you can go to the PCEP again and say, "Optimize the tree," depending on what you want to do. But the next thing you can do is that you can actually use the link failure. You can detect that the port has gone down and based on that, if you have a SID list, you can use the unicast adjacency SID to do a LFA via just a unicast. If you are using unicast to steer the point-to-multipoint traffic out of the port, you can use the unicast LFA to steer the traffic into a alternative path. Or within the same draft, we do have point-to-multipoint—I want to call it a fast reroute, not a LFA, where you can set up a fast reroute path via SR policy, via replication segment, to protect your original port. So you can use that to—to actually do a fast reroute. That's all I had.
51:11 Dhruv Dhody: Thanks. I put myself in the queue. Related to liveness detection, I think if PCEP is involved in this flow, it's worth including. Otherwise, this is just how things are supposed to happen at the PIM and the—in the other working groups, right? When we do liveness detection, we focus mostly on within the PCEP protocol, how do we make sure that everything is up and running. So this information is useful, but I think it could be if it already exists in another document, you can just reference it and say how the PCE, PCEP protocol or PCE and PCC are involved in this flow. Then it is useful in a PCEP document.
51:52 Hooman Bidgoli: So just to make sure I'm getting this correctly. So what you are suggesting is that there should be a paragraph that says the controller or the—the PCE can see the state of the network and based on the failure on a link, it can optimize the path or switch the backup candidate path?
52:12 Dhruv Dhody: Only if that's what it's doing. Right now, it sometimes feel like everything is a local decision then nothing PCE is not involved. So I'm not sure with this description what is the role of the PCE in this process.
52:25 Hooman Bidgoli: So what I thought, and again, I'm open. I'm just giving you my—what I thought is that liveness detection here, it would be more important to say that how you protect local failure or end-to-end tree failure in a fast manner rather than having the PCE recalculate the tree and download a new optimized tree.
52:50 Dhruv Dhody: Yeah. I completely agree for the document in which we were describing how the whole SR P2MP policy works. This document is focusing on PCEP extension, and I was thinking you could if it—if this information doesn't exist anywhere else, then maybe we can include it. But I was hoping this information would be there in some other document that you already have. We could just reference it there and say how PCEP is involved. And then also talk about things like what happens if PCE is no longer there? That liveness detection—that how do I detect those things? Which is already existing, it's not a new thing. PCEP protocol has mechanisms you just relying on that itself. So it's a good distinction, especially when we are doing the operational sections in our document and we do features for BIER, for DetNet. We don't really want to go into how each of these services are doing liveness detection. We want to focus on the PCEP part.
53:45 Hooman Bidgoli: Understood. Okay. I'll massage the text.
53:48 Dhruv Dhody: Yeah. Thank you so much. Zafar?
53:51 Zafar Ali: Yes. So my comment is about this having a lot of detail regarding FRR in this document. Because this—this is a PCEP version, and for anything that has to do with FRR for point-to-multipoint SR policy, should be done elsewhere and should be clarified elsewhere. I would like to see what is the references used especially for the link failure triggering local optimization, which is, which is obviously not something that PCEP is—is—is involved in. But yeah, so I—I think the comments are twofold. One is that having something that is FRR related, some, some description here is a misfit, and it should be done elsewhere and in reference to that. Yeah.
54:51 Dhruv Dhody: Thank you.
54:52 Zafar Ali: Yeah.
54:55 Dhruv Dhody: And I also owe you comments. I was discussing with Andrew who's the document shepherd, and somehow I dropped the ball. So I was looking for my email list and I noticed that I haven't replied to that. So this is just a note to Andrew: I will respond to that and we will—this is anyway next in our working group last call queue, and we will definitely try to progress this quickly.
55:16 Hooman Bidgoli: Sure. Thank you. Appreciate it.
55:18 Dhruv Dhody: Thank you. We were running ahead of time, but I think we are now exactly where we are supposed to be. Okay. So everybody respect the time. We have bunch of presentations we still want to go through.
55:42 Minshe Wang: Okay. Hello. I'm Minshe Wang from China Mobile. And this is a new draft for the 3.2 SRv6 Inter-layer network programming PCEP IPV6 segment routing extensions for the inter-layer network programming.
55:57 Minshe Wang: In RFC 8664, PCEP extension for supporting SR-TE LSP for the MPLS data plane. And then RFC 9603 extends to support SR for the IPV6 data plane and segment routing over IPV6 for SRv6. And it enables the network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPV6 packet layer. So based on the 89—RFC 8986, so we proposed a draft with already an IETF draft SRv6 inter-layer programming, to define a new behavior can be used for the steering packet to the underlay network connection. And we have a hackathon this time, and for Saturday and Sunday, and have two inter-layer multi-vendor inter-layer connections. So for this document, we want to extends the PCEP SRv6 for the inter-layer network to enable the PCE to instantiate the candidate path, both the layer 3 network segments and the underlay segments.
57:34 Minshe Wang: So an SR-TE path consists of one or more SIDs, where each SID may be associated with an identifiers that represent a node or adjacency corresponding to the SID. So this identifiers refer to NAI. So an NAI can represented in various formats like IPv4 or IPv6 address. So however there's no existing layer 3 NAIs applicable to the End.IL SID, inter-layer SID. So we think we need a new kind of NAI for this SID. And simple to—to use a—used for the describe the underlay network tunnel between the two nodes. And underlay tunnel ID is can be configured by the management system and unified identifiers underlay network tunnel. The new NAI mainly carries the underlay tunnel ID. So as the next step, we will continue to improve this document and stay in sync with work in the SPRING. So thank you.
59:02 Dhruv Dhody: Thank you. Any questions? I have one. If we go back one slide, it would also be useful to tell if I'm—if I receive this NAI, how am I using this information? We talked about we are configuring tunnel ID at the two end points, but also it will be useful to maybe explain how I'm—how does this tunnel ID help when I'm setting up the path, for instance. Just as more description.
59:30 Minshe Wang: Okay.
59:31 Dhruv Dhody: Zafar, do you have a question?
59:34 Zafar Ali: No. No. I don't.
59:36 Dhruv Dhody: Okay. Okay. So just as a—I know that the document is already adopted in SPRING, so you're making progress. I—I wanted to make sure that this change that we are proposing is also explain how one uses it with an example or a figure, that how one use this tunnel ID information while setting up the inter-layer path. So maybe a figure or a description would really help and get the point across that why a new NAI is needed.
60:07 Minshe Wang: Okay. We will.
60:12 Dhruv Dhody: Thank you. Any other comments? Thank you.
60:28 Julien Meuric: So the next presenter is Zafar.
60:31 Dhruv Dhody: Yes, Zafar. Just getting you slide control.
60:35 Zafar Ali: Thank you. Okay.
60:44 Zafar Ali: So my name is Zafar Ali from Cisco Systems. I'm presenting this document about 3.3 SRv6 Policy SID List Optimization related PCEP extension. So just a bit of a history. We've been presenting this document quite regularly at the PCE working group. One of the comments earlier was that we need to establish the need for this change from SPRING document. So what we did is that we worked with the SPRING working group. We have a draft there in SPRING working group that is now adopted working group document.
61:30 Zafar Ali: What basically that draft talks about is that when SR policy is established, the last SID of the SR policy could be a Node SID or could be an Adjacency SID. But when the last SID of an SR policy is a Node SID, then if the traffic that is steered on that policy already has a locator which matches the same instance at the policy and the endpoint Node SID, then the policy, and is encoded in the packet, then the—then the endpoint has to deal with two back-to-back SIDs, which is inefficient from a—from the MTU encoding and compression efficiency point of view. So the SPRING draft talks about that in such cases, the—the head-end node may skip programming of the endpoint Node SID. Okay. And that's what is called SID list optimization.
62:43 Zafar Ali: So, like I mentioned, this draft is now in SPRING and it's—it's adopted. So what we going to do next? For the draft that is in front of us, which is the PCEP extension, we've been like for multiple IETFs, we've been making minor changes. There was one comment that we should make the flag consistent between SPRING PCE IDR document, which we have done. We made minor changes. We do not think that there is anything that is outstanding in terms of the comments that we have received so far on this document. We think the draft has been stable. And then with the PCEP—sorry, with the SPRING establishing the baseline requirement, we really feel that the document is ready for working group adoption, and we would like to move this work forward in the working group.
63:43 Zafar Ali: The—the changes are pretty straightforward. Basically, we have a new SR policy attribute TLVs in the policy association object defined. And then within that new policy attribute TLV, we have one flag that we have defined that—that basically says that—the—that dictates that and then we have for backward compatibility, there's a flag in the SR PCE capability. So it's pretty straightforward extension, and we would like to move the work forward. Thank you.
64:21 Dhruv Dhody: Any questions for Zafar? None. Let's move to the next, which is also—
64:33 Zafar Ali: And like just Dhruv and Julien, so would you put this in the queue for adoption? Because that the prerequisite was really getting the SPRING document adopted and the work need for the work established.
64:55 Dhruv Dhody: Yeah. Julian and I will discuss after the meeting. There's nothing that seems like it's blocking, but we would definitely like more discussion on the list for sure. And we'll take a decision and let you know. Thanks.
65:07 Zafar Ali: Okay. Thank you. Thank you so much.
65:11 Zafar Ali: So then the next draft is the 3.4 MSD Consideration in PCEP. It's I'll go over a little bit of a history. So when—when we were working on the previous draft, which is the SID list optimization, Andrew and Dew approached and then mentioned that, look, the same thing happens when you have the first SID of the policy being an Adjacency SID. That first SID does not get encoded in the packet as the packet goes forward. So it is not—should not be considered under the MSD—MSD budget of the device or the head-end. However, when we look at the PCEP RFC, the language was very strict in terms of the way—or language very—and you're going to see that language later on in the slides. But the language was very strict. So we thought that okay, maybe some clarification is needed. Now while we did this, the co-author Leo realized the same thing happens when we have SRv6 encoding for the policy and we are using the reduced flavor of that encoding, then also the destination address is not copied from—copied into the SRH. So that's another use case for clarification or MSD consideration in PCEP. And SRv6 RFC was also very strict in terms of the text that was there. And we're going to go over that.
67:00 Zafar Ali: So with that, basically, like I mentioned, yeah, so this is the text. So the RFC 8664 text is in front of you. It is quite restrictive in terms of the way it's constructed for a head-end node to do any leeway even if it knows that the first SID is UA. Same thing would apply for if the SRv6, if the—if the SRH, if the reduced flavor is used. So goal was to really loosen that—that restriction a bit or find a way to loose that restriction. And from an SRv6 point of view, these changes really apply to the incaps MSD. So the changes that are here are with respect to the MAX-H-INCAPS.
68:01 Zafar Ali: I will go over bit more—like these are the changes. Okay. So the change for SR-MPLS is pretty straightforward. To make it backward compatible, everything is really about the backward compatibility here. There is a capability exchange and then within the capability, then there is a flag defined that can actually tell, okay, yeah, the—the two side understand then the PCE can relax the condition which is in the RFC for in terms of MSD consideration. Same thing for the SRv6 case. SRv6 case has two thing. Obviously, the first SID being the adjacency SID for SRv6 is also applicable. So the what we call A-flag, adjacency SID flag, in that capability is still applies to both SRv6 and SR-MPLS. But in SRv6, there is also an R-flag, which is to do with when you're using a reduced flavor. And then you can relax the MSD consideration. And A-flag and R-flag can coexist obviously.
69:13 Zafar Ali: So like I mentioned, what happened is that because these two things were happening, Leo presented his last IETF, so we had discussion and the feedback from the working group was that why don't the author for the two drafts work together and merge? So that's what we did. We worked together. We have merged the content from the two drafts that are in front of you into one draft that covers both SRv6 and SR-MPLS.
69:45 Zafar Ali: From the update besides the merge, the content from two drafts are pretty much what was presented in the previous IETFs. So there has not been change to—to that in fact—to that effect. And we feel that this has been like—because this work happened in parallel and has been stable for quite some time, so we would like to have working group adoption. We are open if chair and the working group thinks that we are better off just writing a bis and then do these two clarification, these two clarification, we are open to that option as well because that's another option rather than doing any—any backward compatible change.
70:31 Zafar Ali: So with that, I stop here. My time is over.
70:35 Dhruv Dhody: Yeah, Zafar. We don't have any time for questions. So please start that conversation on the list, the one that you just mentioned about is this the right option or should we do bis? And let's debate it on the list. Thanks.
70:47 Zafar Ali: Okay. Thank you. Thank you so much.
70:55 Dhruv Dhody: So we move to the next part with 4.1 PCEP-LS Optical. Shu will present? Yes. Go ahead.
71:08 Shu Xu: Okay. Good afternoon, everyone. I'm presenting our work on the PCEP-LS extension for optical networks. As we all know, a PCE operates on—on the TED (Traffic Engineering Database). Traditionally TED is constructed through the IGP management station, YANG and BGP-LS. The PCEP-LS draft defined some fundamental features. We will—we follow all of them. The base PCEP-LS draft was adopted in August 2024, and now is approaching to the working group last call.
71:52 Shu Xu: The PCEP-LS defined some key functions. First, the capability advertisement. Both the P—during the session establishment, both the PCC and PCE advertise their support for the PCEP-LS. The second is the link state synchronization. The PCC sends link state and information to the PCE. The third is the link state report. The PCC continues to send the LS report to the PCE when the information is changed.
72:34 Shu Xu: Why PCEP-LS is interesting for optical networks? Because the optical network devices have limited capacity for the additional protocols, and the BGP is not running on these devices. But the PCEP is already running for normal PCE reasons. So adding PCEP-LS function is a small increment. The only challenge is that the PCEP-LS only defined some core functions. Our document adds some specific capabilities for the optical networks.
73:17 Shu Xu: Let me walk through the specific extensions we define. We include the node attributes and link attributes in the existing RFCs, assuring the consistency with the existing implementation. The current status is like this. This draft was first posted in August 2016, and it has been waiting for the base PCEP-LS to progress. And now the PCEP-LS is moving, so we have woken up this—this work. We synchronizing with the PCEP-LS draft, addressing the reviews and make some editorial improvements. Now it is more than ready for working group adoption.
74:31 Shu Xu: So looking ahead, since this work is started in 2016, we are now seeing that the working group is evolving. The ODUk can carry thousands of connections, so it increase the IGP pressure, making this work even more important. So we need to make updates to cover the latest optical networks and keep in touch with CCAMP, the optical experts. Okay. Thank you. Welcome your questions and comments.
75:15 Dhruv Dhody: Thank you. Any questions? Zafar, go ahead.
75:25 Zafar Ali: Yeah. My comment—reservation has been about this work is because the BGP-LS already does this. So PCEP base got adopted because it was an experimental, and we have not seen any update—at least I have not recall any update on that experiment. I think is just running this—my concern is just running an a parallel thing for something that has wide deployment across the industry using BGP-LS is—is—that's the major concern. And having that view of that experiment will be useful.
76:12 Dhruv Dhody: Adrian.
76:13 Adrian Farrel: Adrian Farrel. Yeah, Zafar, you're right. The PCEP-LS is experimental. And of course, is still inside the working group. It hasn't popped out. This draft is also marked as experimental and it's kind of continuing that experiment. I would expect to see maybe actually we'll see the result of optical experiments before we see result of packet experiments, and that's—that's probably okay because we will then get a feeling of—of whether there's success or not. But it's certainly not the intention that PCEP-LS gets wide deployment in the internet before we understand results of the experiment.
77:01 Dhruv Dhody: Plus one to that.
77:03 Zafar Ali: Yeah. Yeah. I think the only comment is that the IGP changes for all of these optical thing were done way long with GMPLS. So is PCEP is the right vehicle again is questionable. I—I see some justification, but they are not in the slide, but they are not clear. Thank you.
77:26 Dhruv Dhody: Thanks. Let's move to the next presentation.
77:40 Minshe Wang: Okay. My next presentation is about extension of PCEP for the 4.2 Fine Grain Transport network (FG-MTN) topology resource information reporting and path setup. So there are three drafts here. The first one, second one are reporting and setup separately, and the second one is for the requirement.
78:11 Minshe Wang: Let's start from the requirements. So with some new service demand, the transport technology of FG-MTN and OTN are all moving forward the fine grain hard slices defined in the ITU-T, we have a series of recommendations. And for the Path Computation extension requirements for these fine grain transport network, we have a draft presented this morning in this room for CCAMP. So the requirement is almost approved and agreed in CCAMP. So the reasons for why we need the path computation for those fine grain transport network are two reasons. First is the number of the fine grain TDM channels, it will significantly increasing. And second one is according to the service requirements we—we currently have, the passes from the TDM may change frequently and dynamically. So this for the requirements.
79:30 Minshe Wang: And following is focus on the FG-MTN control and PCEP extensions. So for the architecture, we have the centralized control PCE to do the topology resource information collection and calculates the path of FG-MTN path channel. And the path computation result is delivered to the PE head-end, then we have the distributed control protocols between the devices to allocate TDM calendar slots hop-by-hop. So both topology resource reporting and path setup have not defined for FG-MTN. So we think we can propose PCE to extend to meet our requirements.
80:31 Minshe Wang: So following are the requirements. And for the topology resource information reporting in PCEP-LS, we want to extend the open object. We need a new flag M in the LS capability TLV flag field for the FG-MTN capability. And in the LS object extensions, four kinds of link descriptor sub-TLVs, we need to describe the FG-MTN resource information like parent NRP-ID sub-TLV to indicate the slice ID—NRP ID that link belongs to. And for the sub-slot bitmask sub-TLV is used to indicate the time slot occupation status of all the FG-MTN clients in the link. And then two sub-TLVs on sub-slot bitmask relationship TLVs to indicates the relationship between the occupied time slots and corresponding FG-MTN clients, so both by bitmask and by the enumeration value.
82:01 Minshe Wang: So for the FG-MTN path setup, both PCE initiated and PCC initiated delegation can support it for the FG-MTN path setup. And in the PCE initiated centralized control, we need to extend the PC-initiate message. And in the PCC initiated, we would like to extend the PC-report and PC-update. The object extensions, first we need a new PST value need to be defined for MTN path. And in the open object of open message, this FG-MTN PST capability is can be advertised during the session establishment by the path setup type capability TLV carried within the open object of open message. Then for the stateful operation, the path setup type TLV bearing this FG-MTN PST value can be encapsulated within the SRP object of the PC-report, PC-update, and PC-initiate message. Then for the LSP object extension, can have a two TLVs to respectively specify the ingress and egress address of the FG-MTN tunnel. And then for the ERO object extension, the FG-MTN pass encoded in the ERO adheres to a strictly hop-by-hop paradigm without IP addresses. So each FG-MTN ERO sub-object contains a strict hop indicator with a L-bit set to zero enforcing the strict hop, a new 7 bits type indicates FG-MTN and the server layer port identifier representing either a 5G MTN port or 10G interface enabled in the fine grain model. And then the bandwidth object extension, we need a new bandwidth specific type defined for MTN, where in the corresponding parameter can carry in the generalized bandwidth TLV to express the number of fine grain TDM calendar slots in the MTN LSP. So this draft is mainly proposed to extend the PCE object for the FG-MTN, and the specific procedure will be detailed in the next version. That's all. Thank you.
85:19 Dhruv Dhody: Thank you. Any questions? This was discussed in CCAMP as well?
85:29 Minshe Wang: Yeah. This morning, we just—
85:38 Dhruv Dhody: We have Fatai coming in.
85:41 Fatai Zhang: Yeah. Fatai speaking. So actually, this draft, the requirement draft also discussed in the CCAMP. And so from the CCAMP chair perspective, we think this three drafts, they are more, you know, about PCEP extension for FG-OTN and FG-MTN, so they are in the scope of PCE working group. So Dhruv nearly sent email to you to discuss if the requirement should be progressed in PCE or CCAMP as well. So I saw your, you know, your response to us, and you said you are try to ask authors to make some progress in other working group and take CCAMP as example. So my understand that actually even for the requirement draft, it's still in the scope of PCE.
86:40 Dhruv Dhody: Yeah. I completely agree. What I meant was that we follow the work as it's been done outside. We are not the person who define FG-MTN and what are the attributes. We either rely on what ITU sets or what CCAMP. So my question basically was is those groups ready with us to take on this item or not.
87:03 Fatai Zhang: Okay. But you know, regarding ITU-T, I think actually ITU-T already have done the, you know, data plane technology standards for the FG-OTN and FG-MTN. So this guys, they just plane this kind of thing in the IETF. I mean, talking about the control plane stuff. So, yeah. Good progress in ITU-T.
87:24 Dhruv Dhody: Yeah. Thanks for this feedback. Very useful. And of course we'll do our due diligence, talk to you, talk to our liaisons as well before we take any decisions. But good.
87:32 Dhruv Dhody: So last presentation. Let's do that quickly.
87:49 Minshe Wang: Hello, everyone. This is Minshe from ZTE. I will present the PCEP extensions for 4.3 Bounded Latency. This document has been presented for many times, and thank you for the comments and the suggestions from everybody. And we think we have a rough consensus for most extensions, so we update some of the from version 5 to the version 6. We added some clarification under encoding and the operations of the DPERO, and we update the encoding format of the DLL DLI and the defined as the optional and variable length.
88:33 Minshe Wang: Uh, the first update is the options for DPERO sub-objects. We clarified it must not be carried as the first sub-object and it can be inserted directly after the existing identifying sub-object. And the PCE must select a one DLI type from the seven categories and compute the the deterministic path. So I give some examples for for the deterministic path. For example, if we choose the type 2 and then DLI must carry the deterministic information for time slot. For example, the type 2, time slot A, type 2, time slot B, and type 3, type 2, time slot C. So this is the example for the PCEP option operation.
89:35 Minshe Wang: To address Zafar's concern, we summarized the—the extensions to align with the DetNet progress. We define the metric object to align with the DetNet queue as per RFC 8655. We define the calculation method to align with the RFC 9320. And we define the DPERO sub-object and the DLI type to align with the seven categories. And exception the DPERO DLI encoding, I will present the DetNet field in this DetNet meeting. So the authors think it's stable for PCEP extensions, so could it be adopted first, or it must be waiting for the rough consensus in DetNet working groups? Thanks.
90:33 Dhruv Dhody: Yeah. Thank you. We will discuss this with DetNet chairs, our ADs, and we will keep you updated. Thank you. Thanks everyone. I hope you had a good meeting. If you have any feedback for the chairs, please reach out. Let's continue to make good progress on our documents. And Julian, last message.
90:52 Julien Meuric: Ah, yes. Thank you everyone. Thank you Dhruv. See you in Vienna, I hope.
90:58 Dhruv Dhody: I hope you guys enjoy the social tonight. Yay!
91:02 Julien Meuric: Have fun! Bye.