Session Date/Time: 21 Jul 2026 14:30
[00:00:41] Julien Meuric: Good afternoon, everyone. This is the past competition among working group session. So usual business. Let's start by the note well. This is the second day at the IETf. So either you're already familiar with the Notewell or you're a newcomer on the set of rules that you should be aware of, especially related to internal intellectual property rules within the IETF, code of conduct as well. There are a set of pointers available in this slide, a QR code. In any case, if you have any doubt questions, you may reach out to your chairs or ADs or anyone familiar with the ATF to get more inputs. But make sure that you are aware of the main principles here, including the fact that contributing to the those session is submitted is associated to the intellectual property rights within the ATF. So the session is recorded. So there are some audio and video running. So for presenter, please please make sure that you remain on the cross that is on the floor there. Everyone who wants to say something, please raise your hand, join the queue, and use the mic. People remote, please make sure that your audio is good enough. So ideally, headset is very welcome to have decent condition, decent audio. So as usual, we have Andrew taking notes, but you are free to give him a hand and join the note here. The link is here. I think draft already copied the link in the chat. So feel free to correct, extend, or add additional information there if you feel that some points were not correctly reflected within the note. Make sure also you join the queues within using tool, especially for people in the room. I know that people who were familiar with the previous way of the IETF, not always think about using the clicker or using the medical tool to join the queue, the virtual queue for everyone, but we need that to synchronize people remote and in the room. So make sure you don't forget to join the virtual queue before going to the mic. Thanks. Usual reminders, this is the AGF. Working groups mostly work using the mailing list, so make sure that you make use of extensive use of the mailing list tool. Share your feedback and comments using the mailing list. We are aware, as shared, that there are many of the record conversation happening. Sometimes we're copied, sometimes not, but many of those should also copy the mailing list, the PC mailing list. So make sure that you do it as much as possible. And, also, there are some key steps in the life of the working group, especially at adoption, working with last call, reviews. So the more people do review document, do send feedback, the more the quality of the document is improved, and the the best way forward the document will progress. A couple of useful links, especially the Wiki of the working group that tracks all our queues. We have another option queue and a working global queue. We try to progress them step by step, but it takes time. So if you're already in the queue, be patient. Your document will progress. We'll try to make sure that we don't forget anyone. The GitHub also might be useful. I don't think we will we will use it that much so far, but feel free to make use of it if you feel that your raft or your contribution would benefit of it. Especially to track issue, this is quite convenient to have it tracked in GitHub. The agenda. So we have a very tight agenda, including a presentation that is over time. So I would like people to discuss about the documents presented, but make sure that you don't go too much over your allocate allocated time if you are a presenter. Last opportunity to bash the agenda. I don't see anyone coming to the mic, so let's move on. Let's look at the working group status. So we now have 77 RFCs published, which is quite large. Wanted to emphasize the 75th but we have two more since he started to to edit this slide. So this is good news. We have six within the IESG hands at different level of maturity, and we have 16 that are current working document. And this is where we try to put the the more focus these days. So among those beyond the working group, two new RFCs, the one rated to the draft-ietf-pce-pcep-secure-tls secure with TLS, which is a basic but very useful one. So quite glad this one is published. And the other one, which is really tied to segment routing and the algorithm embedded in PCEP, which is also a very useful document in my opinion. We have three IDs within the RFC editor queue, so at different level of processes. Some are waiting for the editor. Some are in the hands of the RFC editor in themselves, but no showstopper on those one, I guess. And we have three other ones with the, mostly in the hands of the AD. We can focus on the draft-ietf-pce-flexible-grid. It has been updated according to the AD's recently, so we'll try to make sure that all the commands open commands were addressed, resolved. And I think this one will resume its step, and the two other one may need some more discussion. But we had very interesting discussion with this week to try to resolve those situation in a very short term. So we can expect them to move forward in in a very near future. We have some document that have early code point allocation as well. So one of them is the multi pass. It's been already renewed two times, but it's with the RFC editor. So no actual issue there. It's a matter of processing about before the its publication, but that should shouldn't be an issue. The the the other one, the second routing point to multipoint is in working with Glasgow. So we cannot also expect that the allocation the only allocation will be confirmed by a final allocation when the document would published on no particular issue on those ones. Legion, no errata to to mention on the. There are just this usual lesion that came from the ITOT last year already. So we can expect a new one probably next September targeted usually to PC working groups. So this is the formal agent to make sure that the ITOT and the ETF keep correct relationship and have views on the current work in progress in both sides. So usually, when we respond, there is a coordinated response with the the different working group involved on we'll do it if we'll join the the group if the set of working groups wants to to respond to the upcoming one. Then I'll leave the floor to my co chair.
[00:10:04] Dhruv Dhody: Hopefully, we will get them soon, and then we will try to progress this out. Then this is the be in our Wiki, you will see in the adoption queue, we have initial set where we say that this is the ordered queue. And for the others one, we always are, not deciding order too early in advance because we wanna see what we can hear from the community. Community tells us that because of implementations, because of other external factors, the priority for, the documents keeps changing. And we try to also balance, between various different buckets of work that we have. As you know, PCEP is being used in so many different ways, segment routing, PCECC, optical extensions. So we try to make sure that we balance between those buckets, and that's why we have ordered and unordered. So at least in the ordered one, we had decided that we will do the p two m p and which we have already started the working group last call. Working group last call is ongoing. We haven't received that many comments. So, again, please please please use working group last call to provide us comments. Otherwise, judging consensus becomes very hard for us, as chairs and eighties. This is the rest of the documents which are in our queue, so they are coming. In which order is something that Julien and I will decide by the end of this week. We have IFIT document. We are also listing what are the some of the blocking things. As you know, as for our policy, we need implementation section. We need operational section. This is the policies of the group. These are good to have, but you can always take an exception, especially in cases where it is needed, but we need the discussion to happen. Can't ignore it. So that's our position as a working group that we have agreed, so please pay attention to that. We would want to most likely progress the entropy one pretty soon. It's been there for a while, and it's a pretty straightforward, document. So that's maybe a target for us to start, the last call next. Some documents which are nearing working group last call, but maybe have dependencies a little bit. So first is the part segment. This has some dependency on the SPRING document. We would wanna make sure that the normative reference is resolved, so that's why we were not rushing with it. But moment the SPRING things are resolved, we can make progress on our part segment document as well. Sue, you wanna ask your question now or at the end? While while Sue is coming, I can mention status of one more. The PCECC p-two m p is one of our last PCECC set of documents. This is about allocating label at the midpoint. So this is something as well that we wanna progress soon. Yes.
[00:12:52] Susan Hares: Sue Hares, Huawei. Let's go back one slide and then back to this. Okay. There's the p-two m p draft. There's a IDR draft for that. We'll need to work on cross along with SPRING. Going forward, the same through his path, the IDR draft in so just so when we do the final call, do you want those comments on on combinations during your last call? Do you want it chair to chair? How do you want to take those?
[00:13:26] Dhruv Dhody: I think this is one of the discussions I would like to have with our AEs as well and try to figure out what is the right right set of information that we wanna share. What is coordination between just the chairs and the AD, and what is the coordination where we need the whole working group in place as well? So I wanted to get that feedback even from the working group as well. What is the right balance we need to sort of work between us and come up with a strategy and present it to the group?
[00:13:53] Susan Hares: Yeah. What we do what we're I'm starting to do for IDR is to put a removable section where where we capture the details between the working group and then the ISG has it in front. But I'll I'll comment on the list on that. Second thing when we come back to the p two m p, there is a parallel track in BEST on some of the multicast. I believe it's parallel as far as I can tell, but they're both using the some of the same BGP functions, meaning they're both using tunnels. So I think it it as far as I can tell, it's okay. Anyway, I'll I'll put that at the operational places. I'm gonna make comments in the last call and you can put it where you want. We put it in a a removable RFC Removable appendix
[00:14:49] Dhruv Dhody: Yes.
[00:14:49] Susan Hares: In the RFC. Thank you.
[00:14:50] Dhruv Dhody: Yeah. Thanks, Sue. At least the policy that we have taken in PCEP, so much as we always are waiting for SPRING or PIM, in this case, PIM documents to be published, and then our documents are sort of based on that. We have not waited for all other places the same extension is happening because I think that I know that we need to coordinate a little bit, but it's not a blocking point for us.
[00:15:17] Susan Hares: I think I'll make the question to the author. Yeah.
[00:15:21] Dhruv Dhody: Yeah. Thanks. So working group last call is ongoing. Please, comment on that. Yeah. Okay.
[00:15:27] Ketan Talaulikar: So on that aspect, I kind of agree with what Dhruv mentioned. There are this I I call them, like, technology working group for a lack of a better term, like, which does the segment routing part. And then the protocol extensions are done, you know, in different working groups, LSR, PCE, IDR. In this matter, the PCE and IDR, quite a lot of time, the same extensions or same nature of extensions are done in both working groups. The expectation from my perspective as an AD is that they align with the base spec more. So with Spring, of course, alignment between PC and IDR is also welcome So that many a times, it is equal and functionality being, I would say, done in both ways. But that would be probably just, you know, probably more between the authors. In most cases, my observation is the same or similar set of authors that are doing both the works. Yeah. So between the chairs, to answer your question, this is the progress coordinating the progress. Yeah. Please do it with the chairs. Yeah. The review is technical thing. Do it with the working group. Yes.
[00:16:46] Dhruv Dhody: Thank you so much. So let's quickly move to next set of statuses. We have some documents which are also expired, so we are tracking that as well. And the progress is there for everybody to see on this document as well. We had some documents which were adopted and after the adoption have not made progress. So I think people put a lot of work at the adoption, and once adoption happens, it fizzles out. That's like, keep doing the work. You have all the comments that you received during the adoption time as well. Please make an update and keep progressing your adopted document as well. And some of the documents are also on the agenda. So in the spirit of focusing more time on the technical work, let's move forward with our first presentation unless there is a working group ID author who wants to provide some update during this time before we start our agenda. I'm not seeing anyone, so let's move ahead.
[00:17:55] Andrew Stone: So hello. Oh, here we go. Thank you. So here to just provide a really quick update on the operational clarification document on behalf of the coauthors. This draft's existed for a very long time. It was adopted last year. There's some debate between is this gonna be a working group document, you know, for a very long time moving forward or whether or not this is something we can actually wrap up maybe in another year or two. So maybe it's worth for the working group to kind of take that into consideration. The whole purpose of this draft is really just to document and cover what implementations are actually doing today. Right? Operational clarifications. So how the things function, some of the clarifications that have been resolved over the years for multi vendor interop, this kinda covers those topics. So unless anybody has a new topic that's aware of where interop is broken or there's some issues there, I think we're kind of reaching that state where it has essentially sufficient content that should clarify a lot of issues. And the clicker doesn't wanna okay. So the changes from the last presentation. Adrian, unfortunately I don't know if Adrian's here in the room. I may not see him, so maybe somebody relay this to him. He sent comments last year last last year, literally. So it took it took twelve months to finally acknowledge those and actually get some changes done. But no. But seriously, thank you, Adrian, for for that comments and those feedback. So the most of the changes are really to reflect the comments that came from Adrian. Basically, it covers different descriptions, certain terminology use, and just the way the document goes about describing certain things. So it describes most of these changes. I mean, author list is still nice and long. I don't know when we wanna actually have that fight in that battle, but for the time being, it is what it is. There is new text that's added that was actually covered in Madrid where the discussion came up about how do you deal with overload, so PC overload state. So the existing RFCs basically say, if a PC is an overload, don't send it a request. It never really described PCEP reports. And so in Madrid, there were some discussions during the session and offline kind of discussing about how do we wanna deal with this. And basically, the text essentially says, well, no. You need to keep sending reports. You need to keep informing the PC that LSPs are changing state even if it's overloaded, but ideally throttle where you can. And it's very tricky to say where you can throttle because there's significant changes where you want to inform the PC as soon as you can. So the text is basically saying, even though the RFCs say nothing, right, you can just keep reporting. Ideally, if you're in overload, try to apply some throttling where it makes sense. But if there's something significant, make sure that, you know, you follow some kind of local policy and actually send up that information. And then in terms of sections, security considerations, just some loose topics there that talk about, you know, denial of service, which is pretty easy thing to grasp from a PC's perspective. If anybody has ideas for security considerations that need to be covered in an operational document, I'm sure there's a lot. But, really, we don't wanna redefine piece up here. Right? It's all about clarifying what the existing piece of RFCs have. And then manageability, you know, Adrian, again, made a really good point that, you know, an operational document should have a very, very complex operational consideration section. Still quite light, but at least it is starting to discuss some of these topics there. How this document is covering certain issues, what does that mean from a, you know, manageability and operational consideration. And yeah. So next steps. So, again, more feedback, more comments. Like I said, securing an operational considerations. Any kind of suggestions or that you think need to really be covered, that'd be really useful. But I do wanna caution that we don't want to go and redefine considerations for PCEP. We wanna cover considerations that that document is clarifying on. Right? And the impact of what that document is clarifying on. And we don't wanna, you know, boil the ocean and try to cover every possible situation. So what's not in here is, again, what I mentioned at the start, ideally, we find some good balance between when do we think this document has enough to cover, enough clarification, the language is good, we can wrap it up and RFC it. So and that's everything for that one, I believe. Any questions?
[00:22:14] Julien Meuric: I have one. Just to comment, in fact, there is a new question. So it's good for you that you move this one forward, so thanks for the work. I really like this section about the overall the PC, which is already feeling missing piece. And maybe you also should consider other types of messaging or use cases beyond reports. I the the the upcoming presentation later in in the agenda about performance monitoring, we'll add some additional type of messaging. We already have auto bandwidth, so maybe you may add some text there to expand the scope of the overall EPC. And this is useful to tackle their it there, I I guess.
[00:23:01] Andrew Stone: Yeah. It it's the performance measurement, one of the nice changes that we kinda did there was to use notification object. Today, there is some weird quirkiness with PC updates. You know, if metrics changing, how often do you inform the PCC? I think different implementations might decide, well, I'm gonna report periodically versus report on every time the metric along the path changes. So maybe, yeah, there's some additional content that we cover there. Yeah. It's a good idea.
[00:23:25] Dhruv Dhody: But just be careful. Like, you we decided earlier on that this was supposed to be only clarification. Amendments is the second one
[00:23:32] Andrew Stone: Exactly.
[00:23:32] Dhruv Dhody: That you would so we have to still balance based on this is what's already there, what's already in the published RFCs, but we are just making it easier for implementers to Interpret. Interpret it. But I'm actually one thing which I we would want to have a discussions with AD as well on how ISG is gonna interpret this type of a document. And this discussion, at one point, I think before we do our last call, I would like, like no. Ketan, just giving a heads up to you that this is not a very usual document that you usually see. Some people would say, oh, if it is this, why are you not missing? Some people will say, why is it is an update. This is a very live debate that we usually get at the working group. This is our way of saying, no. We are not changing the base spec in any way, but some implementers who have found a hard time interpreting things. We wanna clarify them. We wanna use more examples in a way to explain how things are done. That was our attempt with this document, which we need your buy in and support to get it through as well.
[00:24:35] Ketan Talaulikar: Okay. So full disclosure, Andrew asked me the question in the corridor. I have not reviewed or read this. That's what I told him. So I'll do that. I'll I'll I'll get back.
[00:24:51] Andrew Stone: We were having a chat later. I'm like, hey. Did you read that? He's like, oh, there's a lot of docs to read.
[00:24:56] Dhruv Dhody: So. So let's move to the next one.
[00:24:59] Julien Meuric: We're gonna go next one.
[00:25:10] Andrew Stone: Okay. So I'm here to talk about amendments to stateful-pce-pce-pcep. So this is basically content that was forked off of the previous one. So the previous presentation is all informational, whereas this one is actually updating existing RFCs. So it's changing the behavior that's already predefined and presenting this along the coauthors or for the coauthors. Like I mentioned, that's been presented a few times. This also goes back many, many, many years. It basically updates some very specific content inside the existing RFCs. So, specifically, there's three major topics. One was stateful LSP bring up mechanism, describes how you essentially skip PC requests. The other one is it's discouraging the use of s r ROs and SRv6-EROs. The reality is you have an ERO signal down. The ERO always reflects the ERO anyway, so you can essentially omit it. So there's implementations out there that omit it. And then the third one was actually raised, I believe, sometime last year as well, which was how to deal with orphan PC and LSBs. And so the recent updates are primarily in that that scope. So yeah. So the text basically clarifies essentially what happens with orphan PC and LSBs. So today, if you have a PC that pushes down a PC and LSP, the existing RFC basically says, well, you can ask for it back from another PC or the PCC can delegate it. But if you're asking for that delegation, there's nothing actually says that the PC knows when to do that. So that creates interop issues because different vendors might have different rules, and there's no messaging or signaling inside of PCEP. So from the orphan LSP side, it basically just discourages and says, don't use that mechanism. Just allow PCC to re delegate, you know, depending on local policy to allow migrations and so on. Yeah. So that's basically the the text is kind of just reemphasizing and redescribing those behaviors. It is an update to it's listed there. I think there's, like, three different RFCs that get touched. Ideally, this is all that we really need unless there's something else that other people raise those kind of issues. So yeah. So this document actually isn't adopted yet. And so looking for a working group adoption because we think the the content's necessary, and two of these items are already deployed in production. So be quite good to get this kind of wrapped up too. So thanks.
[00:27:31] Julien Meuric: Any question, comments in the back? Well, I have one again. Thanks again, Andrew, for holding the pen on progressing that work. The the document in draft, I like the wording that you used to refer to stateful on stateless bring up. It clarifies the different situation. And I like the fact that you don't want to remove completely what has been there for long, but want to open the door based on implementation feedback, I guess. What is missing from my point of view is that when you use a request, you know from the protocol specification that you need a response. You need a reply. When you do an update, you just rely on the PC implementation to get a feedback, but a PC implementation could never respond to the the ODEP. So maybe you you should mention something about that and say that we are deferring the decision to respond to the PC implementation, knowing that the typical way or maybe lowercase should could be used there. I I don't know what's the best way to address it, but I'd be glad to to see that kind of change, which is significant from the the specification of the protocol, be tackled in the the document to make sure that we are clearly describing what we are changing even if the industry is okay now. Maybe someone else will come with a new implementation in the future result without the networking background that you have as Nokia, for instance. And you never know. So I'd like to make sure that it's tracked in the document.
[00:29:12] Andrew Stone: So if if I just respond to that with an example. So if you do stateful turn up today, you report with delegation, PC computes, there's no solution. PC can just stay quiet. So you wanna make sure that it's documented to say, hey, PC can stay quiet. Don't always expect the PC update, for example, unless there's actually a reason to signal a path. Is that a good Yeah.
[00:29:31] Julien Meuric: That's the kind of situation I'd like to be mentioned and tackle.
[00:29:34] Andrew Stone: Yeah. Makes sense. We can definitely add that.
[00:29:40] Dhruv Dhody: Thank you. Thanks.
[00:30:04] Rakesh Gandhi: Good afternoon, everyone. My name is Rakesh Gandhi from Cisco Systems presenting this draft on PCEP Extensions for Performance Measurement (PM) in Segment Routing (SR) and MPLS Traffic Engineering (TE) LSPs, PCEP extensions. On behalf of the authors listed here, we'd like to welcome Andrew. He joined the draft. Looking forward to working with you, Andrew. We already were. So agenda, we look at the requirements and scope overview, the protocol extensions for capability, attributes, and notifications for delay, loss, benefit, diligations, and liveness. There is new notification messages. That's the delta, basically, since this was presented in last time. And next steps. So requirement is to measure the the p metrics, delay loss, and whatnot for SRT for both SRMPLS and SRV six as well as MPLS TEE. It's an end to end measurements so that it can take proactive, reactive actions, and we can avoid the degraded parts when stateful PCs in the network. We can also do the real time bandwidth utilization for, like, if you want to implement auto bandwidth at pc. So scope is the pc or pc initiated LSPs for both SRT and MPLST. What's not in scope is how the PC will use the metrics or what protocol we will use to measure those metrics or the telemetry for the controller and whatnot. That's out of scope. So just a big picture overview in in terms of pcep extensions. There is measurement capability. The second one is the measurement attributes. And the third one, the measurement objects. That's used to be a report message. And thanks to Andrew. Now it's a notification message. So first one, the capability. We wanna know if it's capable of delay measurement, loss measurement, liveness, one way to look back. All of this is useful to expect what kind of parameters that we can measure. The second one, the once we know what the capabilities are, we want to have attributes to enable some of them, all of them, the the intervals for the packets, measurement protocol, the reporting thresholds or report interval and and whatnot for various delay loss, aliveness, bandwidth measurements. And the third one, this is Delta since sends an is a note notification message to notify the measurements. So there is a bit complicated message RBNF here. There is a list of LSPs in the notification. We kind of did optimizations so that if we don't have to carry the ERO and RRO to optimize the processing of some of these notifications. There is also a multipart related RBNF added as well. And then, obviously, notification contains all of the measurements that's done. And again, this is optional. And in the notification, there'll be parameters for the delay values, one way, two way, or look back values. Same way, there'll be parameters for the loss, how many packets were received and as well as measurement is active or not active or there's error. Same way for the liveness state and the bandwidth values being sent. If pce does get overwhelmed, there is a message to say to tell pce- to temporarily suspend, hold off. So welcome your comments and suggestions. If you think this is useful functionality to have, let's work together as a working group document. And that's what I have. Thank you.
[00:34:37] Julien Meuric: Any command from the audience or question?
[00:34:39] Dhruv Dhody: We have Lizard.
[00:34:41] Julien Meuric: Okay.
[00:34:48] Lei Zheng: From Harvey. Could you please go to page six? Yes. I think I see on the left table, I see three flags in, and the last one is our flag. It means the loopback delay measurement. So my question is, what means look back is a runway or something else? So there is SR PM
[00:35:24] Rakesh Gandhi: draft that talks about using stamp, how to do it. So in one way, it's basically only the forward direction. Two way means that you point the packet. So let's say if you're doing timestamps, you have t one, t two, t three, and t four. And two way means you do t four minus t one minus t three minus t two. And look back means that it's just t four minus t one because you don't have the timestamp from others' side. So you don't have t two and t three. So just a let's look back. So the SR PM draft describes some of these things. But if you need more clarification,
[00:36:04] Lei Zheng: we can add in the draft. Oh, okay. Thank you.
[00:36:12] Dhruv Dhody: I think you should definitely reference it, which we don't right now.
[00:36:15] Rakesh Gandhi: Yeah.
[00:36:19] Julien Meuric: K.
[00:36:23] Dhruv Dhody: Any other comments? Since I'm the coauthor, I'll have to ask Julien to talk about adoption.
[00:36:36] Julien Meuric: So I think we can do first poll in the room.
[00:36:47] Dhruv Dhody: Maybe we should have prepared the question.
[00:36:49] Julien Meuric: Yeah. Which I didn't.
[00:36:54] Dhruv Dhody: I'm seeing less number of people who have joined the Meetecho, so this is good time for you to log in as well. Oh, you wanna start with red? Woah.
[00:37:11] Julien Meuric: Old school. Yeah. To have a rough idea.
[00:37:20] Dhruv Dhody: Just seeing how many people are paying attention.
[00:37:24] Julien Meuric: Wake up.
[00:37:26] Dhruv Dhody: Your emails can wait.
[00:38:14] Julien Meuric: So now the main question.
[00:38:27] Chenqiang An: Just a reminder that I'm not sure you have mentioned the unidirectional delay or it's round trip delay. So to just to distinguish the two two delays. And I also suggest to refer to the existing existing IGP metric. For example, you you should advertise their IGP metric. For example, the the directional link delay. And then you measure the the directional delay to the real delay and the constant link delay. So I suggest to refer or to add some reference to the related their their metric.
[00:39:34] Dhruv Dhody: Yeah.
[00:39:34] Chenqiang An: So I'm not sure you you have done that.
[00:39:37] Rakesh Gandhi: So you are right that in ISIS and OSPF, RFC, seven four seven one, I think, talks about unidirectional link delay. But there are drafts in IPPM, for example, like stamp drop that talks about one way and round trip delay. So there are many different names. So it's one way or unidirectional or two way or round trip and whatnot. So maybe we can add some more context in the draft to say, this is also known as this in this RFC or something like that. So it's it's obvious that, you know, they are same thing.
[00:40:23] Chenqiang An: Yeah. Yeah. It it will make sense. Yeah. Yes. Thank you.
[00:40:27] Rakesh Gandhi: Yeah. Thanks, Jim.
[00:40:32] Julien Meuric: Thank you. So it seems that there is some interest from the working group, but even though everyone hasn't read draft. I see one now, if someone wants to tell us what may be against the adoption of draft, that would be very useful as sync. I don't know if it's someone from the room or remote. So I don't see any anyone coming. So, hopefully, I would be happy we would be happy to hear from the person who said no to express their concerns on the list. From our point of view, it seems that it's a decent amount of respond that allows you to join the adoption queue, And then we'll confirm on the on the by pulling the the mailing list if we can adopt the the document. In the meantime, you'll have some time to socialize a bit more the document to have more people review or at least read it, get more feedback, and that will be very useful to progress it as a working group document later, hopefully.
[00:41:46] Rakesh Gandhi: Okay. Yeah. That's good.
[00:41:47] Julien Meuric: Thank you, Rakesh.
[00:41:48] Rakesh Gandhi: Thank you.
[00:41:52] Julien Meuric: Next presenter is Oman.
[00:42:02] Hoomanan Bidgoli: Good day. So this is for the SR P2MP Policy. We uploaded a bunch of versions within a short period of time, so I I thought maybe it's appropriate to give a little bit of overview of what we did. So first thing, I just wanna clarify some of the drafts that are here. So there are the mother drafts, 9524, nine nine sixty, and then there is obviously OAM one for MPLS only. We're gonna make so the SR point to multipoint policy obviously works for segment routing MPLS in cap and SRv6 in cap. But as you can see, the OAM is only for MPLS, so we will update another draft. We will upload another draft to pin to address the lack of OAM in SRv6. So the next one is the MVPN and EVPN as our point to multi point overlay. So this just I got the email that has become RFC to be, and the RFC to be is 10,018, I wanna say. So, anyway, you can have a look at that. But just to make sure everybody understands, this is the overlay. The one in BEST is the overlay draft, meaning that we use that to signal the multicast route from one PE to the other PE. It has nothing to do with nailing down the point to multipoint segment routing tunnel into the data path. And nailing down the point to multipoint tunnel into the router, that's where the PCE draft and the IDR draft comes into place. So that's the difference between those three best PC and IDR just to make sure that you guys are in line because I think there was some confusion at the beginning with the chair of the IDR. Okay. So what did we change from so if you want to compare the drafts, I recommend compare version 14 with version 19 and don't get lost in all the subversions between fourteen and nineteen. So the first thing that we kind of updated is we made sure that it's very clear that the existing draft is only for MPLS incap. I think me and Andrew, we're gonna put another draft in for s r v six, whether it's a copy paste or I have no idea. It should be a good read. The thing that we did is that we beefed up the errors. So there are new error types that we ask from the INA for SR point to multipoint policy specifically for all the messiest stuff that can happen when there is a communication from the PCC to the PCE. The third was we incorporated the multi multipath backup. I still have mixed feeling, but I bow to the working group. I think this multipath backup, the fact that we brought it into the point to multi point policy will come back and bite us in the behind. So just so everybody knows, what this backup was is that, let's say if you have a candidate path and you want to nail down a static backup, you want to nail down that my outgoing interface primary is interface one. And statically, you wanna say that, by the way, my backup is interface two or three. That's what this TLV does. We had that so that's why we kind of created the multi path draft back in the days, five years ago, when I was younger. But, obviously, we took it out because we felt that, I guess, LFA is the way to go for fast reroute on the unicast side. Again, everybody have a thought about it. As I said, I bowed to the working group, but we'll see what happens later on. So, anyway, the backup is in the multi point to multipoint draft now. On the CCI object, we just wanted to make sure that the RFC 9050 talks about the CCI object using the PC initiate and PC report message. It does not talk about the PC update message, so we made sure that the the audience understands that in this specific draft, the PCC message actually is included into the PC update message app as well. We did some editorial changes. I mean, thanks to the chairs with all the comments that they had brought up. And from the BNF point of view, when it comes down to downloading the point to multipoint policy and the replication segment, Again, my BNF language is not very good through, thank you very much for all the updates that you actually put in there. So these are the main changes that went between version nineteen and fourteen. And, obviously, the chairs have put on the last call. You know, have a read. Any last comments that you folks have, you know, more than welcome. And that's basically all I have.
[00:47:35] Susan Hares: Perhaps I was not clear in my comments. I was dealing with administrators separately than technology. I'm now going to deal with technology and the comments I said I was going to delay. First of all, I want to start with a strong complement to your current set of drafts. They are, for the most part, coherent. I would I have some minor suggestions as far as which SPRING you referenced to, but overall, they are fairly solid.
[00:48:10] Hoomanan Bidgoli: Thank you.
[00:48:11] Susan Hares: Very good upgrades from the previous IVR, very good upgrades from other things. I will relook at the best EVPN. However, my comment has to do with the interaction between various proposed drafts. We are beginning to look at how pce changes something, what might happen to for IDR to change something. You did an excellent job during your presentation of saying this is where IDRs work, This is where PCE. Again, that's a very good portion. As you put finish your IDR draft, if you would put that information as well in the IDR draft in an appendix which will be removed. We hope that will speed you through your ISG process. Third, my concern about the technology has been with the use of the tunnel encapsulation r c ninety twelve. There is a third one using there is your set of work, which is in pce, which is in b g p with the tunnel and caps. And then there is and I suspect, as I have not refreshed myself, that the EVP and draft, I'm not sure what it does. But the one I was concerned with was the multicast controller out of BEST, which also uses the tunnel encapsulation. So what we need to my comment is we need to look at what happens if that launches something and we have errors if you're in conflict. That is the whole of my comment that we have two place two things using the same mechanism that are doing pretty much as far as I can tell the SPRING general p-two m p or something related to it by replicating having replicated segments and leaf segments. So somehow we've got to come to text that says either these better be ships in the night, meaning they won't they shouldn't be in the same network or you need to tell me what happens if they do. That's called error handling, I believe. And that was the only major comment. If that also said wanted to say it here in pce because you may have pce trying to do it the your best draft, their best draft. How do we detect or do we simply say to the operator, don't do that. It will hurt. That would be a fine answer, but that's my feedback. That's it.
[00:51:02] Hoomanan Bidgoli: Yeah. So, sir, so let me refresh my your memory as well. So we already been through that conversation, that draft that you're talking about from Bess. So the I think that was done by Jeffrey, and he was using different route types to download the replication and point to multipoint policy.
[00:51:21] Susan Hares: You are absolutely correct. I have I have recently reviewed that with him, and I will speak with him again on my review.
[00:51:28] Hoomanan Bidgoli: And I I think the conclusion was that with the point to multipoint policy, because we are using candidate paths, we wanted to borrow from the unicast implementation of downloading the candidate paths, the same type of objects, the same type of TLVs. So this is why we created the IDR, which is kind of inheriting heavily from what the unicast is doing for downloading the candidate paths into the PCC. So, again, the final conclusion was that the draft in BEST will yank out the point to multipoint policy, and it's just gonna be used for RSVPTE or maybe LDP. I'm I'm not sure. I think it was mostly for RSVPTE. If you wanna nail down a RSVPTE tunnel through a controller, the best is gonna use that, and we're gonna yank out the point to multipoint policy, which is gonna be the idea.
[00:52:28] Dhruv Dhody: I think let's focus on the PCEP part. And I think for PCEP part, the biggest question, which I think which I got from Sue was the idea that in a network where you're using both BGP, PCEP, and a yang to do things, what is our operational guidance we wanna give?
[00:52:44] Susan Hares: That that's how I have
[00:52:46] Dhruv Dhody: The thing is it's not just their draft. This thing happens with segment routing and for this all the time, and I think we need help to put something in operational consideration, which is a generic advice. It's not something very specific just for multicast either.
[00:52:59] Susan Hares: That is my comment on this draft. The other information you gave me is extremely useful, but as I think Dhruv said, we probably should take that to best where I will ask the same question. I'm happy with all the the if that's a solution, that's great. We just have to document. And for PC, all we need to do is have that cross.
[00:53:27] Dhruv Dhody: Thank you. Thank you. Thank you, Sue, for all this coordination work that you're doing. Thank you. I also joined the queue. Thanks, first of all, for taking all the comments and updating. My main focus in the initial set of comments was just to make sure that we are ready for working class call. I have further comments which I'll send you, so please be sorry. That's alright. Thing which I wanted to bring it out to the working group as well was, like, have a look at the appendix and especially the part where we are describing how the message flow is. This is a a feedback that we sometimes get that piece of messages are difficult to understand. And when a new set of folks starts to use piece of, they they struggle. So this set of authors believe that the representation for doing that is something that we have never tried before. So I I didn't wanna go against it. I it's an author's choice. It's in the appendix. This shouldn't be the blocking thing, but I want more feedback from the group to look at and see, is this the best pictorial representation of message flows that we wanna do, or should we rely on the existing ways in either when we do diagrams or we we use other notations? We should create not one more way of doing things in a hope that that will make things simple but create a brand new confusion. So that's the reason why I wanted to highlight and get more feedback from the groups, especially on the appendix, the way in which the messages examples are being described. So when you do your working group last call review, please look through it. Zafar.
[00:55:01] Zafar Ali: Zafar, I actually there was some discussion on section four three six on FRR, and I'd like to get some clarification as part of this process on that discussion and making sure that those are comments that address there. There is we can talk a bit more offline, but I'd like to record that. Do you need to go back to that discussion?
[00:55:22] Dhruv Dhody: Yeah. Working through last call is going. Please give your comments. Let's resolve this. Yeah. Thanks.
[00:55:29] Julien Meuric: Thank you.
[00:55:34] Dhruv Dhody: What happened? Okay. I pressed something incorrect. Okay. I wanted to share slide. The binding set.
[00:55:54] Samuel Sidor: Hi, y'all. Let me fix that. Hi, all. Samuel from Cisco speaking. I will be I will be presenting draft about the Binding Label/SID Extensions
[00:56:27] Dhruv Dhody: Oh, yeah. It's not working. Anyway, I'll do it for you. Just keep going. Yeah.
[00:56:34] Samuel Sidor: So the even my slide is not not switched. I can maybe be streaming now. So what is the about? In piece of the whole already binding label/SID RFC, which is describing how binding labels/SIDs and could be in piece of TLVs. It is describing the process of the allocation from PCC and from PC point of view. It is describing it for various OSP types. But we have also a a sort of policy architecture, which is describing the fallback if the allocation is not successful, so in case of the conflict. But that that fallback behavior is not defined from PISA point of view. What the existing PISA policy is describing is in case of conflict, complete message needs to be rejected or must be rejected. And so that means PC can potentially retry to create LSP again in a different binding label, but it is not the one with what SR Policy architecture is describing. So what the proposed extensions what are the proposed extension in this draft? We are trying to to cover the fallback part. We are trying to describe the behavioral two different behaviors. One is falling back to the creation of the LSP, but keeping it in downstate just be while the conflicting behavior or while the conflicting binding seat is allocated. The second option is to fall back to local allocation of the binding label. So different different binding seat or different binding label is allocated on PCC side, and it is reported back to PC. So p c PC requested some label. PCC fallbacks to different label and responding back with both values with the requesting one and allocated one. For the recent changes which happened since last presentation, we renamed one of the flags, which is which is defining the capability POV because of the confusion which was caused by two different flags, which were using the the name of the or the which were called f flag. There are multiple multiple changes in in multiple sections of the draft. Some of them defined or the the one major change which happened is basically defined ordering from the two TLVs, which are including the requested and allocating binding seat. There were there were qualifications done in the operational and backward compatibility sections. There are multiple multiple extensions for the error handling, new error types, LSP error code value for explicitly indicating what was the problem if the LSP is is blocked in the downstate while the while the conflicting behavior is is still in progress. So that's probably it. I'm keeping it short just to just to keep keep the working group informed about about the changes which happened. I would also ask for the I would like to ask for the adoption. So, basically, the draft is there for some time. It's relatively stable, and the I I hope that there there are no no no more major changes to to the draft itself. Thanks a lot. Any any comments?
[01:00:17] Dhruv Dhody: Questions? Thank you.
[01:00:43] Lei Zheng: Good afternoon, everyone. This is Lei Zheng from Huawei. I introduced the PCEP Extensions for Network Resource Partition (NRP) on behalf of my call call from Huawei, Citi, China Mobile, HP, and Cisco, and also individual. So this this strata was adopted as a working group document in November 2020 file, and we also submitted version zero one to improve the readability and also updated the others from Huawei because one of the others has left Huawei. Okay. So the updates from zero zero version to zero one version, there are key changes is the way you change the TROV name from NRP TLV to NRP-ID TLV. This is along the way to the the TROV name in BGP. And we also updated our introduction for the r for IP ID and the KPI KPI to line with its definition in in the the in the NRP draft in TS. And so we can recap the intentions for p PCEP. Firstly, we introduce a new which named RTTR into our NRP object. It includes RTTR, which is a unique unique 32 bit identifier into NRP domain. And then we also have a flag fail fails, but no no flags are defined. And then we also have some subtitle fails, and it can be used for future to carry some additional informations. And we also introduced PCEP Capability, is used to indicate the p sub capability supported by PCC or by PCE. So for this attention, the first case is it can be used for RP aware pass computation. In this case, the NRP-ID TLV should be carried in the LSPA object of the RPC request message to indicate that the NRP assets are constrained for past computation. And the the PCs then uses network resource and the topology attributes also related with the NRP parameters in the past computation. And if for the past computation is failures and the PC reply message, it can carry r p NRP-ID TLV to indicate that the computation in the specified NRP is not successful. And, also, it can be used in NRP to pass update or report. A PC can include that there's a TLV in the p t update message to indicate that that's at the in which the t parts need to be updated. And if this update is successful, successful and does the PCC should include this TLV in a PCR p report message to indicate that that's the NRP image that t pass is updated. And if the if the NRP-ID in the message does not match with the NRP-ID of the use case c and t t pass, and the the should keep the LSP not unchanged and include error code in the PC report message. And as a second case is RP specific path initiations. This is initiated by a PCE. The PCE may include this TRE PC initiate message to indicate the NRP in which the path needs to be initiated. And depends on the deflag in the PC community. The PC can use either NRP specific resource of or did apply NRPD in constructing the t pass. And if the pce determines that r r t parameters in the pce initiate message are not acceptable, it must send a error message to the pce. So we also shows the progress of our peer related work in other working groups for our ENTs. The network rely network's device framework has been published as RSA. And, also, multiple networks last draft has are moving towards working group last call. And, also, in screen and idea are multiple networks drafts are the I s three review are ready for working group last call. And, also, MPRs are all six months. SR-MPLS encoding is also in ISG or working. So I think we need to align with the progress of our PC and NRP draft and the others. So now for next step, I think that this draft now is quite stable and mature, and we welcome for remain on the comments from the working group. That's all. Thank you.
[01:06:50] Dhruv Dhody: Any comments? Zafar?
[01:06:57] Zafar Ali: As for release ecosystems. So there is a draft in SPRING that defines kind of a data model for policies and and the NRP. And that draft is not referenced. I I noticed it's not referenced by this draft, but that dependency there. And there are some pending comments on that draft in the SPRING. So I like to make sure that whatever is done here is aligned with the Spring Always. Data model. But but I was I may be wrong, but I did not see the reference here. And also, yeah, g is coming. G, if you can address the pending comments, we can discuss offline.
[01:07:41] Lei Zheng: Thank you for asking. My colleague is.
[01:07:45] Jie Dong: Jie Dong from Huawei. So you mean the SPRING and the as a policy and NRP draft. Right?
[01:07:54] Zafar Ali: Yes. Yeah. This one. Draft-ietf- SR policy NRP.
[01:08:00] Jie Dong: Yeah. Actually, I think the scope of this piece of draft is slightly broader than the SR policy because it can cover general SR SRT or other t pass computation based on the NRP constraint. It's more generic, but I think it can also be added rather informative reference.
[01:08:26] Zafar Ali: I think we can discuss offline, but I don't think this is informative because the base model, base data model is in the SPRING draft. So I do not think this is informational, but unless we can take offline, but that's one thing that needs to be addressed. And that discussion inclusion needs to happen on SPRING.
[01:08:49] Dhruv Dhody: At least in my reading of the document, it is not SR policy specific. When they say that they can carry this in LSPA, I assume that, like, no, they are trying to do it in a much more generic fashion than this. But as an informative reference, that when you are using this with SR, it is the SR policy and RP that describe things in the perfect way. That's the best way for us to handle this thing,
[01:09:13] Zafar Ali: in my opinion. That that is fine. I think I just I'll I wanna make sure that this draft is able to address the ASR use case properly and everything is aligned.
[01:09:26] Dhruv Dhody: Thank you. And there have been NRP documents in the ISG recently. There were lots of comments. Just make sure that, like, you you handle this those comments in your documents as well. Don't wait for ISG to tell you those things again.
[01:09:39] Lei Zheng: Yeah. Thank you. Thank you.
[01:09:42] Dhruv Dhody: There was just one thing in when you were mentioning about NRP, aware path computation. I think right now the terminology that we use is a very generic terminology that we say PC should consider NRP. We need to be a little bit more specific that when I'm doing a part computation, what does it exactly mean? And since it's about interoperability, we have to make sure that it's a little bit more concrete on what does what does it mean to do part competition with NRP in this. Am I saying it should only be the notes and links which are belonging to the same NRP? When we talk about bandwidth and other resources, it should be exact. I I think we need to go a little bit more than just a should. Thank you.
[01:10:25] Lei Zheng: Yeah. Okay. Thank you.
[01:10:38] Susan Hares: We are back to delivery.
[01:10:41] Julien Meuric: Yes.
[01:10:41] Yao Liu: Hi. I'm Yao Liu from ZT, and this draft is PCEP extensions for past delay difference. So now a single PCEP LSP can contain multiple forwarding passes. So typical cases include the first is a load balancing. So now multiple EROs can carry within a single piece of LSP. And another case is to point to multipoint. So point to boundary point LSP originates from a root and benches out out to multiple leaves. Although, logically, it's a single LSP. It can actually it actually compromises mass multiple independent branch passes from the root to different leaves. So in some cases, the end to end delay difference among different passes or branches need to be controlled within a certain range. So for load balancing, the flows of the same service may be hashed to passes with different latencies. This will cause uneven completion times for service tasks and will degrade application performance. And for p to m p, so the latency differences among late passes can cause loss of a synchronization across receivers, naturally impacting user experience for services such as video conferencing and live streaming. So this doc document proposed that a mechanism is needed to allow a PCC to request a delay difference among passes or branches does not exceed a specified threshold. So the extension is simple. So we defined multipath delay difference metric, and it prevent it represents a difference between the maximum pass delay and the minimum pass delay among all the member passes of the same LSP. And the usage is similar to other PCEP messages, p PCEP metrics. The PCC may use this metric in pass completion, a request message to request a saddle pass within an LSP meeting the end to end delay difference requirement. And the second usage is a PCC can also use this metric to request a PC to return the computed the multipath delay difference value for the saddle passes. And the PC may use this metric in a pass competition. A computation reply message along with a no pass object when the PC cannot compute a set of passes meeting in this constraint. And that's all. Welcome feedback on comments.
[01:13:57] Andrew Stone: Thanks for the presentation. When I read the draft, I was confused a little bit on the use case, specifically in the multicast. So I can understand from you wanna have your receivers synchronized. So if, know, you people are watching TVs in different areas, they all receive the same feed. In that situation, you if you're optimizing for lowest latency, you just optimize on the lowest latency, right, in general? Because if you say all of your receivers are getting the lowest latent path, you can't do better than that. And so that would achieve the end result. And the other side that I'm looking at is you might say, okay. Well, maybe you don't take the lowest path, but you need to take a path that's within a certain differential. Otherwise, what do you do? And if the rule says, please get in this differential and there's no solution, then you're not gonna return a path, which means you're not actually gonna provide a service. So is it better to have people receiving different feeds at different times, or is it better to have nobody receiving feeds? And I suspect most people would prefer delay than no service period. And so if you wanna do that kind of connectivity, just do short as delayed routing. Right? And do your multicast, for example, your p two m p on short as delay. And then everybody gets the lowest delay you possibly can, and you can't do better than that. Right? Physics won't let you achieve more than that. So I I I I think the document probably needs to evaluate the use case. Like, is there is there value in turning down the connectivity? Because if you don't satisfy these restraints, well constraints, then what's the alternative? And if you can't satisfy that gap, then I I I struggle with that. So thanks for that.
[01:15:42] Yao Liu: Thank you.
[01:15:45] Hoomanan Bidgoli: Yeah. Nokia as well. I I think Andrew kind of said some of this stuff, but I think this needs to be run by PIM. I think there's a misunderstanding with multicast. You cannot optimize a certain part of the tree multicast. You need to optimize the entire tree. So optimizing the entire tree, that means that that entire channel goes away, and you need to rebuild it. There could be procedures of make before break to do that. But if you're in the middle middle of the World Cup and suddenly you start optimizing your stuff, there's gonna be a riot. That that is something we could so you need to clarify all this stuff here that how you're trying to make this work for multicast. As I said, the way that I read it right now is, like, I kind of felt that you're trying to optimize a certain branch of the multicast. And I I I honestly I think this is a p c PCE job that the PCE needs to read the end to end latency of the entire tree with all the branches and equally set up all the branches again with the same latency. I don't think you can optimize a certain branch. Just a feedback.
[01:17:01] Yao Liu: Okay. Thank you. I have to think about the multicast multicast cases. Yeah.
[01:17:06] Chenqiang An: Thank you.
[01:17:06] Dhruv Dhody: I think sometimes too many use cases are not as useful. Find the use case, which is where this is needed, and just focus there. Thank you.
[01:17:26] Chenqiang An: Hello, everyone. It's from CT. I will talk about the Extensions for Computing-Aware Traffic Steering. Yeah. This is a little document, but we have updated for two versions based on comments from the mailing list. Okay. We consider their computing metrics during their past computation and their at their new metric type in the metric object. And we add their operations, security, and the I n a sections to modify the the whole document. First, I will clarify the motivation for the PCEP extension for CATS. From the CATS framework, the C-PS can be filled as a PC for CATS service. So C-PS will as be will be filled, will will be deployment be deployed ASRPC. And the first, it will collect the metric information from the C-SMA, for example, the computing metric. And there are the c from to collect the network metric from the C-LMA. This is the existing metrics. And it will determine the best path is to forward the CATS service. So it is different for PC in CATS framework. First of that first of all, the PC, the the C-PS as a PC should select the egress cast forwarder. It's it is different from before because in PCEP, their head their head point endpoint and their the end end the the end endpoint will be carried in their PC PC required message. But from for this scenario, we will just know the the egress, but we don't know their cat the the we just know the ingress, but not their egress. We just we just know their ingress and the point and the surface ID. So we lead to the the PC should select the the egress route first and then computer the path associated with their computing metric. So this document proposed the the PCEP extensions for selecting and distributing their the passes forecast service. So as I just mentioned, we proposed a new metric object. We a metric new metric type for for CATS because the the the CATS has to collect their their computing metric other than their existing network metric. So we add a new metric type for computing metric to to be viewed as their new metric during the pass computation. And we also add a new flag, c flag, to indicate that this is their pass computation. This is a requirement for from their for the CATS surface pass. And we also add some TLE can be filled as the CATS metrics during their pass computation. For example, CSID TLV. The c s I CSID is defined in the CATS framework to identify their CATS surface. So as I just mentioned, we carry their CSID in there to us to select the path collecting with that surface ID. And we also can carry the c s I c s CIID to identifying their their particular surface instance to for their CATS service. So and finally, based on their ingress CATS forwarder and their ID and the instance ID, we can select their their the egress CATST forwarder and computer the path and distribute the path to their to their ingress CATST forwarder. So we propose the c flag to indicate the the egress router for CATST surface.
[01:22:38] Dhruv Dhody: Let's ignore the encoding and go to the main message. K. Yeah. Let's move forward.
[01:22:45] Chenqiang An: Okay. So this is p sap operations. We need to carry their metric object in and we carry their c flagging the RSP object to indicate the CATS surface CATS pass computation. And we also distribute the the ERO or SRU or SRO. With six ERO to insert their their c flag to indicate the egress route. So last step, we will correlate to and keep this ID to consistently aligned with their cast working group. For example, their their protocol document, it will be presented in working group. So Thank you. Thank you.
[01:23:43] Dhruv Dhody: Any quick question? Otherwise, let's move. We are running late. Thank you. Could you help us move faster? Focus on the update?
[01:24:04] Christian: Let's do so. So later, everyone. This is Chris from Telefonica. We present an update on this path computation based on precision availability metrics. So So a little brief history. So, basically, here, the purpose is to take into account the statistical behavior of the path at the time of taking the decision. So not only the metric as a measure in in one single point on time, but also the the history of of the behavior. So till I presented the updates in 2007 until 2006. Our approach was to define to to propose to define a a dedicated precision metric object that, basically, the focus was on extending the PC with that new object and and consider the computation being driven by this PAM specific metric signaling. After the comment received, especially in in ITF-one hundred twenty four, we basically changed the direction and the idea now will be to reduce the existing objective function framework that is defined in RFC 53 fifty five forty one, define PAM oriented optimization objectives, and basically reporting the result to the to the to the client, so basically the decision taken. So the new document orientation basically defined two functions, the PCC request apart using PAM constraints and PAM objective functions. And as output, we return the statistical characterization of the way of the path selected, and we include this in in the repo in the report TLB. So the path objective functions that we are defining or considering, and and this is, let's say, an initial work, probably we need more iterations on that, will be the compliance against the PAM the precision availability metrics. So, essentially, to select the path with the highest compliance with the these precision metrics, essentially, the path with a a statistical behavior closest to to the requested metrics, availability metrics. A second object function could be the minimum violated intervals in the histogram or or CDF. So according to the statistical function being chose chosen. Sorry. And the third one, the minimum severe violated intervals. These violated intervals and severe violated intervals is something that the precision availability metrics define in the RFC in in IPPM. So the the way the flow will be essentially to, yeah, to once that we receive the request, we retrieve the the information of the behavior of the path. We create the statistical characterization. We compare against the the constraints and the objective function, and then we select the the path best matching best that is statistical behavior. As a summary, we have presented this. We have changed the direction according to the comments that were provided by Rakesh, by Amal, and also by Drup. And and basically, here now, the point will be to to collect feedback if this the direction is, yep, is is correct, is appropriate. And if so, keep working on refining the draft for the next meeting. That's all. Just that.
[01:27:03] Dhruv Dhody: Thank you so much. I'm being so quick and right on time. Any questions? Okay. Thank you.
[01:27:09] Christian: Thank you.
[01:27:18] Zafar Ali: Hi. So my name is Zafar Ali from Cisco. I actually start to socialize this idea of policy driven Implicit TLS in PCEP because in a lot of deployments, you have PCEP and then TLS underneath and both endpoints are known through policy that they will run TLS. So I started to visualize with with other vendors and I'm happy that there are other folks as well that are thinking the same way. So what we are asking is the information drop, but what we're asking is that the in 8253, when we define hand shaking or learning that my peer speak TLS through the pcep using the start TLS, that is that is fine, but that it just, that message itself go in clear text. So it introduced some some security issue as well. So what we are saying is that if the two peers already know through management plane that they are to run TLS, then TLS is completely independent. It's something provided by the transport like TCP. So TLS handshake happens completely independent of pcep. The pcep and TLS work completely independently, shifts in the nights, and that simplifies the pcep state machine, and there's no need to learn the capability. But it is within the context that the both peers know this thing from management plane, and there's no fallback without TLS possible. So but and another important point is that we are using the existing TCP ports. So this we're not asking for anything. So this is really informational in a deployment where where these conditions satisfies, we could do that. There's some, obviously, benefits of simplification and state thing, but more important is that it's backward compatible in the sense that implementation can support RFCRE two fifty three. And this profile configuration or implementation can deploy clear text is is is is the TLS layer and the TCP layer independence can be achieved, which is which is clear, goal here. Is that there's no need to have TLS information at the protocol layer. And that's really the stuff. This is informational completely. You just say that we can do it without the start TLS.
[01:29:57] Dhruv Dhody: Any comments? We have one minute quick feedback from anyone. The feedback that I gave was, like, let's go back and look at when we were developing this RFC earlier. We had all the debates. At that time, we had choice between start TLS and having our own port number. The advice that was given to us by security people was, no. Start TLS is the state of art. Do start TLS. So now the question would definitely come, what has changed between then and now? And we should have a good answer of satisfying that. And let's work with them. And time is over, but let's have that conversation on the mailing list.
[01:30:33] Zafar Ali: But they we're not asking for any new port. This is using the existing port. It's just a different deployment profile. That's it.
[01:30:41] Dhruv Dhody: That's And that's a very valid question that every if every protocol that we currently have an IT of does the same, how would that impact? They will think from that point of view. I know we sometimes focus very much on a piece of implementation thing. Isn't it gonna be simple? But we have to also think holistically. Does it make sense when there are gonna be other implementation of piece of which will be expecting start TLS? Some would be clear text. So and you have now this another implementation which expects implicit. So we have to be careful, and let's work through the security folks and get a right way to handle this. I'm not saying you can't do this, but do it right. Yeah.
[01:31:21] Hoomanan Bidgoli: Yeah. Hooman and Nokia. The the only feedback I can give you back is we implemented TLS on RADIUS and other and usually, as great as Pisa is, that first communication
[01:31:34] Jie Dong: was stiff.
[01:31:35] Hoomanan Bidgoli: That first communication that you need to negotiate the TLS capability between the PCE and PCC via p l TLSSr, that that that is a little bit off the like a black sheep that no other protocol out there does it, like RADIUS or TACACS or any so, usually, all these other protocols, when you wanna do TLS, what it does, it brings up the TCP. And as soon as the TCP is up, the first thing that it does, it does the TLS handshake over the port that the RFC mandates, and then it brings up
[01:32:12] Dhruv Dhody: Yeah. And and in most of those cases, that that was there from the very start. It wasn't that TLS was introduced much, much later. At least that's my assumption that why we were told that start TLS is the best way for us to handle a protocol that already has a clear text version or at least saying that with TCP, use TCP m d five. That's how we started. And we moved to TCP AO, and there are so many different things. So the the, this is with the security people when we discussed back in the day. What I'm saying is when we wanna do this, let's talk to the security people early rather than we do a lot of work and then we get the grief. That's what I'm saying.
[01:32:49] Zafar Ali: Sounds good. That sounds good.
[01:32:50] Julien Meuric: Yeah.
[01:32:51] Zafar Ali: Thank you.
[01:32:52] Dhruv Dhody: Thanks, everyone. See you in San Francisco. Maybe not.
[01:33:00] Julien Meuric: I'm sorry. All online.