**Session Date/Time:** 21 Jul 2026 12:00

[00:00:23] **János Farkas**: Okay. Good day, everyone. Welcome to this session of the IETF DetNet networking group. The group is co chaired by Lou Berger next to me and myself, János Farkas. And we have our secretary, Yves Hertoghs, on-site doing a great job. You can find the logistics at the usual places. And as a reminder, by participating in the IETf, you agree to follow the IETf process processes and procedures, policies. This note value is a reminder of some of these policies. You can find the details in the links and you can also scan the QR code. I would like to remind you that all the contributions become a permanent record of the IETF and whatever you say as well as contribution. Also, reminder that IETF participants are expected to behave with respect and courtesy to their colleagues, and you can find the details in the conduct guidelines. On-site, please scan the QR code for the virtual brochure. Remote participants, make sure that you are muted when you are not speaking. So note taking is a joint effort, so please join us with the note taking and make sure that everything is recorded correctly. We need to capture the essence of the discussion only. And we have a very packed agenda. Some items have been removed, but we would like to ask you to keep the time. And the time on the agenda includes the time for discussion as well. For the working group outdoors, we would like to ask you to focus on the changes from the last meeting and what are the plans to complete the document. And for non working group documents, we would like to ask you to focus on what area of the working group charter is being addressed. If it is not a new document, what is the what are the changes? What are the next steps? And a status update on the working group, we have two new RFCs published. Both are coming from the reliable available wireless work. The raw technologies and the raw architectures have been published. Many thanks to all who contributed. This was a great effort. I started as a standalone working group and then folded into DetNet. Nothing in the RFC editor queue at the moment. And we have a few working group drafts that are not on the agenda for today. Liaison statements since the last IETF. We have two liaisons from ITU study group thirteen. This one on the screen is for information. This is informing us to that networking group on the progress of the work items related to deterministic networking. And the most recent one that came in out of the last plenary is for action. There are four items in the liaison. So the purpose of the liaison is to inform the DetNet working group over the much majority of one of the ongoing works related to DetNet and also seeking feedback from the DetNet working group. So they actually ask ask the DetNeting group to review the new draft recommendation and provide feedback, especially as it is related to the stateless fair queuing draft, which is item three on the agenda today. So I suggest to discuss the details of a potential liaison. We should send or expect to

[00:04:32] **Lou Berger**: send the liaison back to ITU-T study group thirteen on our work. And everybody is welcome to contribute, so if

[00:04:40] **János Farkas**: you are willing, please contribute to the development of the response. Just a reminder on the IPR, we do the IPR course at each step in the process of the document development. And to progress our work, we mainly use the mailing list. So please utilize the list. We can also have virtual interims as needed and inform our working group meetings. So please contact us if you see a need for such meetings. And as a reminder on document status, we expect that all the working group authors to provide a status update. So we have most of them on the agenda, but not all. And for those ones that are not on the agenda, we expect an email to send to be sent to the list. And actually, we are missing some updates for some of the draft. So please provide the update. That's the intro part and moving to the next. That is know?

[00:05:52] **Lou Berger**: So the taxonomy. And please remember to please join the note taking to help capture discussion. Thank you. Do you have the clicker?

[00:06:04] **János Farkas**: Yes. Oh, I can

[00:06:06] **Jeong-dong Ryoo**: Hello, everyone.

[00:06:08] **Lou Berger**: I'm live. This house go advanced. Yeah.

[00:06:12] **Jeong-dong Ryoo**: Mic is a little bit high. Just a second. Thank you.

[00:06:28] **János Farkas**: No. It should work. At least it doesn't work. Right now.

[00:06:31] **Lou Berger**: Right now.

[00:06:33] **Jeong-dong Ryoo**: Okay. Yeah. Thank you. This is about the taxonomy draft. I will just read through the slides so that you can can have a question later. So the taxonomy draft is to facilitate the understanding of the data plane enhancement solution. We have quite a lot of solutions for now. The taxonomy draft has defined one performance related criteria and four functional criteria. It has specified two reference topologies. It has specified seven suitable categories. So currently our data plane in and solutions must be one of these seven suitable categories. Right? In this version, version six, section eight considerations for interoperability between solutions is revised to be a complete form. In doing so, a new document is referred which is DetNet multi domain framework, which which also has been adopted recently. So in this revision, we have been discussing about the interoperability. It is defined between technological domains. So the technological domains is the defined term in that multi domain draft. So we we have adapt adopted that term in this taxonomy draft as well. It defines how well solutions can operate without specialized treatment both in data plane and control plane. So we have come up with two metrics. One is operability, which defines the interoperability, how each how each it is to integrate functions in the control plane. So that's the operability. And this aspect will be covered by the the multi domain framework as well. And the data plane pass, in the data plane operation, we have come up with the so called performance metric, which defines the feasibility of the consistently meeting the requested service levels across the entire data plane path. So this is the newly added table, which was incomplete before, but now in its complete form. It it is just an example interoperability levels. On the right side, in the x axis and y axis, we have we can have at most seven suitable categories, but in this table, in this specific table, we only have two suitable categories. And we have defined how well they are interoperable with each other in terms of operability of control plane and the performance in data plane. So the plan. I think the document is very stable now. It has not been revised since like one year for now. We don't have any more revision plan. That's it. Thank you. Questions?

[00:10:12] **Mike Johnston**: Hey there, Mike Johnston. Thank you, Ryoo, for the update. On the interoperability section and the table you suggested, what's I was looking at the draft and it's not kinda clear what should be done with the output of that and whether something is low, medium, or high. Doesn't seem to have any kind of implementation kind of considerations or implications. Is there is there a plan to add that?

[00:10:48] **Jeong-dong Ryoo**: Could you could you speak up a little bit? I cannot hear

[00:10:51] **Speaker 4**: Sorry.

[00:10:52] **Mike Johnston**: I'll go a bit closer. So the this table, it doesn't kind of go to the next step, which is what is the implementation implications of something being low, medium, or high. You have we we have the three levels. Mhmm. And on medium, I'm not quite sure where that fits between low. It fits in the middle between low and high. But what does that mean for someone who's looking to implement this?

[00:11:21] **Jeong-dong Ryoo**: Right. Okay. Thank you. Thank you for the question. Before answering your question, I have to say that this is the informational document which tries to give the information without any implementation issues, without any standard issues. The background of this document is to facilitate the understanding of the data plane solutions which is currently being developed in this working group. There are about six or seven such solutions which we will review today. This section of draft is to categorize those solutions and how well they can perform in specific scenarios, in specific reference topologies, and so on. So this is just an informational. There's nothing more about it.

[00:12:21] **Lou Berger**: I I think we're also contribution driven, Mike. So if you have additional suggestions on what to add, please send it to the list, and we can incorporate it. Thank you. We always welcome opportunities for improving our documents. Okay. We're gonna move on to the next, which is also a. I can here. Let me do this. You have to cancel. Oh. You should be able to do it now. Oh, maybe I can.

[00:13:12] **Jeong-dong Ryoo**: Thank you. This is about the latency guarantee with stateless fail queuing. I have to confess that these slides are quite long, having 13 pages, and I only have ten minutes. So I will try my best to go through all the contents, but let's see. Okay? So this is the overview of the Cisco draft history. It has been started 2023, but it has been adopted to working group only recently, this year April. It is one of the data plane in an symmetry solutions. And it is categorized by the taxonomy draft as a flow level rate based unbounded solution, which is a suitable category. And this revision is the version number one. In revision one, this version, there is an addition of the estimation process of the total service rate of the link. To be exact, such a a process should be used. That term, that kind of statement is added in 6.3 or the emission control. So what has been added here is the one sentence inside the red box. The total service rate of the link is estimated by the mechanism specified in wider QS, SRE, RF. So that statement, only the statement is added. So as such, the that ITU-T document, the Y.IETF-QS-SRE-RF, is added as a reference, of course, whose title is Routing Mechanism and Framework for Service Rates Estimation with Packet Metadata for Stateless Admission Control, which is under consideration within ITU-T SG13 and is about scalable stateless service rate estimation for admission control. And this document is based on the Cisco framework and Cisco metadata. And it requires an added metadata. So as such, again, in this revision version one of Cisco, a metadata is added and their according head formats are defined in close six dot one and six two. So at this point, I would like to say what is the relationship with ITU-T standards. So I try to summarize the relationship with ITT standards and why working in both SDOs in this diagram. So in the upper part, you you can see the ITT standards and the ongoing draft, which is Y.3129, Y.3148, and the Y.IETF-QS-SRE-RF. These documents define high level requirements. And in IETF, we also have existing standards regarding the RSVP. For example, RFC twenty two zero five, twenty two ten, just to name a few. And about IPv6, we have RFC eight thousand two hundred, eight thousand five hundred and four, and so on. And we are also having ongoing work related with MPLS MNA, MPLS network action draft that is being developed. So adopting those high level requirements into the Internet, we have to carefully coordinate with the existing IETf standard. And that is what this c score draft in IETF, the networking group, is doing. It defines the implementation details.

[00:17:30] **János Farkas**: Can we stop here for a bit of a discussion?

[00:17:33] **Speaker 5**: Okay. Yeah.

[00:17:35] **Jeong-dong Ryoo**: Oh, for for the question. Yeah. Mhmm. Okay.

[00:17:39] **Lou Berger**: So we've had some discussion of what is appropriate for here versus what is happening with the ITU-T document. I'm gonna forget the name, but it was on the prior slide. The thing we wanna be really careful about is to not repeat the same definition in multiple STOs. Right. Given that this work is going forward, I think it's back one slide, right? Go back one I

[00:18:11] **János Farkas**: know, but

[00:18:11] **Lou Berger**: do you mind going yeah. So, given this work is going on in ITU-T, and you saw that we received a liaison about it actually today

[00:18:21] **Speaker 4**: Mhmm.

[00:18:22] **Lou Berger**: We wanna be very careful to ensure that what we're doing is aligned with this document, and is not covering any of the same material

[00:18:34] **Jeong-dong Ryoo**: Mhmm. In this document. Right.

[00:18:36] **Lou Berger**: Yeah. So if there's anything in the in the IETf document that is repeating information in the ITU-T document, we would need to remove that.

[00:18:48] **Jeong-dong Ryoo**: Right.

[00:18:48] **Lou Berger**: And it we it's perfectly fine, and we've done this with TSN documents. Perfectly fine to reference the other work in the STO, the other STO. But we don't want to repeat or redefine.

[00:19:02] **Jeong-dong Ryoo**: Right.

[00:19:02] **Lou Berger**: Yeah. So we have to be very careful, and I know Okay. You said careful in the next one. I appreciate that. And it seems like we have some disc we in the past, there's been some misalignments. I'm not sure if there's misalignments now. I haven't had an opportunity to document. But it's something that we're gonna have to go forward with. And one of the comments made by our AD happens to be in the room. Actually, don't remember if it was our AD or a different AD, is that when we go to the IESG, it will be blocked if we are not haven't arranged the text in such a way that we're not stepping on toes. We're not repeating information. If the group agrees to put forward a document that duplicates what's in the IQT, it will not progress.

[00:19:57] **Jeong-dong Ryoo**: It

[00:19:58] **Lou Berger**: will not get published. So we have to be very careful not to do that. I understand. And we have a couple of people in queue.

[00:20:05] **Jeong-dong Ryoo**: So my brief answer to Lou's comments, I think it's it's more like an advice than just a question or comment. I I totally agree with Lou. Two most important thing is the coordination alignment and then non overlap. Right? So, you know, we are trying our best to not overlap with the ITT standard as well as having the perfect coordination or alignment with those standard. Thank you. Mike? Yes.

[00:20:38] **Mike Johnston**: Thanks. And I'd just like this is Mike Johnston again. I'd just like to echo what Lou, the chair, has just said. And I've said on the list before that we should not be duplicating work that is done in the ITU-T and the previous slides you had of the kind of relationship between the different standards. We should talk about some of that in more detail in a minute. I think you have some further slides which in particular relate to the liaison that we've just received today that we should talk about in more detail. But there seems to be a bigger issue around consistency, coordination, and cooperation between what's happening in ITU-T study group 13 and what's happening here, even though some of the same authors and contributors are here. But I have specific questions on some of the stuff you haven't got to yet, I'll step away.

[00:21:33] **Jeong-dong Ryoo**: Okay. Thank you. Hi.

[00:21:37] **Speaker 6**: Since Lou brought it up as the responsible lady, I would strongly recommend that this clarification of overlap and, you know, what's complementary with the other STO be resolved in the working group. I do not believe it should be something that should come all the way till the ISG. That would be just not right and it would be too late. So please Okay. Do all the collaboration Mhmm. And all the clarifications while the document is still with the working group.

[00:22:10] **Jeong-dong Ryoo**: Okay. Thank you. You. Okay. I'll I'll proceed. So I think the time is quite up. So, yeah. I will skip this slide. This is this slide is about the mechanisms specified in ITT document, how the service rates of the flows can be estimated. But you can take a look at the ITT documents later, and I will just skip this slide. So this is the revised header format according to the added metadata. We the fourth one the fourth one with the red red box highlighted. That is the edit one. That is the title of the metadata is the difference of finish times. It is actually the difference between the current package finish time and the previous package finish time. Okay? So yeah, I only have two minutes. And according to the MPLS post post stack M and A, the first metadata is put in like that form. But I'd like to highlight that not only the post tech m and a is considered. The instec m and a can be also considered, not that part is not yet covered in the draft. Okay. So far, we have discussed about the added metadata and how it can be implemented in MPLS header and IPv6 header. This is the from now on, I would like to discuss a new stuff briefly. This is section eight of the draft, which is about how to approximate c score. Okay? Cisco is a very has a very good performance related yeah. Cisco has a very good performance, but it has a little complex. It has a a bit of complexity. That is to it has to sort the packet according to their finish time. Okay? So we have to have a priority queue such as pushing first out, p four. But some of the high speed routers cannot afford such a pi four, so we have come up with an approximation technique, which is a little bit complex. So I won't go into the detail. In essence, it is based on the rotating strict priority schedule. So as we all know, strict priority scheduler is very common, implemented in every router, I would say. Only the only thing we need is the rotation of such a priority of the SP, strict priority scheduler. With that rotating type of strict priority scheduler, we can approximate the c score very efficiently. It even has in theorem four theorem three, you see that there is a mathematical end to end latency bound, which is very close to the c score latitude bound. As you can see

[00:25:34] **János Farkas**: Okay. For for for the time, maybe we can skip the simulation and go to your future plans Yeah.

[00:25:40] **Jeong-dong Ryoo**: Yeah. You can see the simulation results by yourself. And future plan is like this. We'll fix the header format. I just show showed you two types of header format, MPLS post stack and IPv6, but the exact format is not yet defined because we need to coordinate with other solutions as well. And then Sorry. Okay.

[00:26:08] **Lou Berger**: I mean, I I that was a mistake.

[00:26:10] **Jeong-dong Ryoo**: And then I will update the ITT document to align with the current hour draft and the newly developing draft as well. Yeah. Thank you. Any questions?

[00:26:28] **János Farkas**: Mike, please.

[00:26:32] **Mike Johnston**: Hi, Mike Johnston. I'm sorry to be up here again. So a bit a bit of history here on this. This this draft relates to the liaison statement that was mentioned at the start of the meeting. And that liaison statement comes from the last study group thirteen meeting, which I was in and Jeanu was in in Geneva regarding a draft that's ready for consent at the ITU-T and this draft because the one that's ready for consent at ITU-T uses four metadata fields, and this one until the new draft was put forward a couple of weeks ago uses three metadata fields. And that's inconsistent, and we needed to fix that. So the proposal here seems to be to change it to four, which would fix the specific issue in the liaise in the liaison, but also requires going back and changing two other ITU-T standards, which only

[00:27:26] **Lou Berger**: use three.

[00:27:27] **János Farkas**: So we

[00:27:28] **Lou Berger**: we we actually are out of time on this. Yeah. So we've received the liaison.

[00:27:33] **Mike Johnston**: Yeah.

[00:27:33] **Lou Berger**: I think you're suggesting perhaps some things that might go in a liaison response. We welcome that to the list. Also, we've said that this document has to be aligned with what's done in the ITU-T. This group has no influence as a group on what happens in the ITU-T. Certainly, individuals will work to coordinate, and we appreciate both of you who are working on on the alignment. But the document will have to be aligned what comes into the IT, from the ITU-T. We don't control that here. And look forward to We'll have to look forward to that in the future draft. If we're not aligned, it We will not make it through the ISG. It will not get published. So it's in everyone's interest to ensure that alignment. Yep. Thank you.

[00:28:22] **Luis Miguel Contreras**: Okay.

[00:28:23] **Lou Berger**: And with that, we're gonna move to deadline based forwarding. Thank you. Thank you, Janu.

[00:28:40] **Peng Liu**: I'm pulling from Tableau. So it's a data live based forwarding. It's draft. So the updates of the draft now is the zero one version, and we simplify some document content for easy reading and define some abrasions such as the EDF and the core definition about, say, draft. And there's a main updates to remove the options including reshaping plus, starting the queue, the reshaping plus rotating priority queue. Originally, we have four options, but now we focus on the optimal options of the two. One's the latency compensation plus 32 q, and another is latencycom compensation plus RPQ. So the reason is that we want to follow the requirement document that for the scalability, and we don't want that every nodes could maintain the the the state of the flow. So we want to make a stateless solutions about it. So it's a main updates of this draft. And the field future plan is to supplement the definition of core terms and highlight principle of composition mechanisms of the options and then supplement the description on how to apply c EDF in the overall network. And we will welcome any further comments. The draft text itself is has a lot of page, so if you want to know more about it, please read the the draft. And in this presentation, we won't say so much about the solution itself. So any comments on this draft?

[00:30:47] **János Farkas**: Any comments, questions from anyone?

[00:31:12] **Peng Liu**: K. This one is time slot queuing and folding t graph. So it's also the zero one version And here the here the updates to address the comments received to add a section operational consideration to describe how to apply this mechanism in the overall network and push section evaluations into the index part, and we polish the text and revise the editorial errors. So for these solutions is you can just realize that the solution between CQF and ATS. So we we implement a case shader part to put the flows into the time slot and to and to reduce the complex with the TS solutions and also can realize the different delays and about the different flows. So for the simplicity, just remove PTM detection, focus on a BUM detection, and we remove the global time slot style. And it's the same. The text for this draft is really long, so if you want to know about it, please read the draft. And the future plan is to supplement description of class based or flow based features. And based on the discussion, the decision of the working group, merge with to provide a single time slots scheduling mechanism. And welcome any further comments.

[00:33:21] **János Farkas**: The other one maybe. There is another one behind.

[00:33:24] **Lou Berger**: See if it's turned off. Might be just switched off. Use the other one.

[00:33:39] **János Farkas**: The other one. Geno, use the other one.

[00:33:46] **Jeong-dong Ryoo**: Thank you. Thank you, Peng. I I remember that in the last meeting, we were almost on the agreement that this scheme and a total less TCQF is a little bit different.

[00:34:02] **Peng Liu**: Yes.

[00:34:02] **Jeong-dong Ryoo**: Because one is based on the flow, the other is based on the class. And not only those traffic granularity, but also about the traffic path. Because, you know, the flow is something the the set of packets that share the flow paths, right, and the to end the paths. But in about the the class is not about such a path. So I'm not so sure if those two solution can be merged easily. That's my question.

[00:34:37] **Peng Liu**: Oh, okay. So if I understand right, you you you mean to merge them too. Right? Or you you say they are different?

[00:34:50] **Jeong-dong Ryoo**: Yeah. I put it differently. Have you ever considered technically merging these two solutions into one?

[00:35:00] **Peng Liu**: In fact, no.

[00:35:04] **Jeong-dong Ryoo**: Okay. Thank you. Yeah.

[00:35:09] **János Farkas**: Any further questions coming? Hello? Yes, please.

[00:35:15] **Carlos J. Bernardos**: I have

[00:35:15] **Xiaofu Ji**: some more complimentary for discussion for the much of for the kicker of your father. How you replied in the that maybe from maybe as a case of. So in technical point, I think there's no any broker issues for merging. But that is just based on the decision of working group. We will need more discussion. Thank you.

[00:35:49] **Peng Liu**: Yeah. Well, the voice is not so clear, so just to to make sure there are no no takers about about it. So thank you.

[00:36:04] **Lou Berger**: So I think if you could repeat the comment to the list, that would be helpful, just because you didn't come through too clearly in the room.

[00:36:33] **Yunchao Liu**: Hello. I'm Yunchal Liu from M3. Today I'd like to present updates in the draft on time porting version two. This draft has been updated to the version two by adding appendix chapter for the mathematical proof and this draft aim to the guarantee the minimum and maximum end to end the latency. It belongs to the low level non periodic bounded category. Main update of in this revision is the addition of the appendix a, which is provide mathematical

[00:37:25] **Balázs Varga**: flow.

[00:37:27] **Yunchao Liu**: Because in previous meeting, working group requested a more mass mathematical justification for how to guarantee the packet transmit before the maximum departure time. So in this appendix eight demonstrate that if the automation condition is satisfied, every forwarding node transmit packet within its porting budget, thereby guarantee both node to delay bound and and to return return spot. In addition, we have added also, who helped me to this update and algorithm implementation on FPGA and testing research of testing performance. So this is key idea with the measurement described for for all packet for all packets minimum and maximum departure time are determined based on the Buffalo configured load delay low and upper bound. And the packet are occurring in packet occurring in ascending order according to their nominal departure time and can be decued over the minimum departure time. As a result, the train delay experienced by packet p depending on only the traffic scheduled before the packet p. We call this traffic preceding packet set in this scheduled packet. Therefore, the worst case screen delay is determined by the total amount of the traffic contained in this preceding packet set. Consequently, in the worst case screen delay is smaller than the forwarding budget. This screen delay is smaller than the forwarding budget. Then the packet is guaranteed the departure before the its maximum departure time. Then question is how we estimate the worst case proceeding traffic. First, we for each flow sharing the output port, we can calculate the bounded budget contribution denote as the Raj b. This value represent the worst case additional accumulated post that flow j may contribute to the processing packet set at node I. Because this algorithm can only transmit the packet. Because this algorithm can only transmit the packet within the forwarding budget, the amount of the burst that can increase while the I think through the nodes also limited based on the forwarding budget as initial burst plus service rate multi modified the forwarding budget, the hope to note I, assume that all node to have a same budget. Thereby the worst case processing packet set can be estimate by summing this bounded burst or over the flow and most case, delay can be obtained dividing the output link rate. Automation condition is worst case. Curing delays are smaller than voting budget. Table this table is illustrative example. Aggregated worst case of bust corresponded to about twenty two point five microsecond, which is smaller than the configured voting budget. So therefore, automation condition is satisfied. This update is first time we include the mathematical proof. We plan to integrate working group feedback and comment, ensure to the

[00:42:40] **Luis Miguel Contreras**: whole draft.

[00:42:42] **Yunchao Liu**: So thank you.

[00:42:44] **János Farkas**: Any questions, comments?

[00:43:02] **Yunchao Liu**: Please. Thank you. I'm in. This this draft has been updated version two by adding new method for calculating the elizability elizability time and finish time. This draft to aim to the provider deterministic and attend the latency and jitter according to the flow rate. And it belongs to the flow level rate based left on left bounded categories. The main update is the addition of the new elizability elizability time and finish time calculation method called the arrival based method according. Chapter chapter 5.2 is divided to subsection. Subsection one is describe the existing directed method, and subsection two is a new new editor, whatever best based method. In addition, also we added course of channel choice. We proposed a new method. Existing it it existing direct method. We call the direct method to calculate the elizabeth time and finish time at the previous node and transmit the time in in in the packet header and subsequent to node use receive the that time directory without any state management. And Julie arrive added the arrival based method to calculate the e t m f t based on the local observe observe the packet arrival time with scheduling gap and delay component in the packet header. Scheduling gap is referred to the difference between the previous node ideal service finish ideal service completion time and actual actual service completion time. Derivation state starts from the equation five. Delay equation five referred the delay factor function. This consists of service delay factor and load delay factor and time difference factor. Time difference factor is defined as a difference between the actual service completion time at node h and packet arrival time at node h plus one. Substituting this definition into the delay vector function, the time difference function is naturally deflates by the packet over time as shown in the equation seven. After so we can obtain the finish time can be deconstructed using the packet arrival time and scheduling gap and delay component as shown in equation a. So arrival time based method is no longer required to express knowledge of the clock difference and propagation delay at node because their effect are already already reflected in the observed of the packet over time. Currently, n score and c score solution has been implemented on the FFPGA now and it's currently being tested. So we plan to apply the current network in future and publish the performance testing result next time. Thank you.

[00:48:00] **János Farkas**: Questions, comments? Okay. Thank You

[00:48:12] **Luis Miguel Contreras**: have it.

[00:48:24] **Carlos J. Bernardos**: Thank you. This is Carlos J. Bernardos from University Canada-three presenting on behalf of my co authors, the draft- a control plane framework for multi domain networking. Oops. Sorry. This document was first presented as a individual submission in. Actually, this comes from previous presentations on the topic of of multi domain that we we basically evolve addressing the comments and feedback from the working group and the chairs. There was a working group adoption call in in March, and it was finally adopted. And we submitted the version zero zero, basically the same as the submission. And then version 0.1 that was submitted in June incorporating the feedback that was received during the adoption call. So thanks for all the people that contributed to with feedback and comments during the adoption call that are listed at the bottom of the slide. So a main quick summary of what changed in one versus what was in the version. Basically, on the one hand, there were many things that didn't change. So we believe that the basic stuff according to the feedback received so far is stable, which is a good sign. So we didn't change the domain definition section, which I believe based also on the past feedback is key for the discussion to really understand and reach a consensus in the working group. What do we understand by domain in the context of DetNet? The product statement, assembly use case, the two coordination models that are considered at this point, and other sections. Then based on the feedback, I will go I will not go now to list because this is included in the next slide. But we did some changes in terminology, in some terms, some requirements, and also some changes in the functional requirements. So as I mentioned, there are many things that stay the same, which is good. I would like to, as I will say in the last slide, to call for your feedback. Now that is a working group document. So it's a document from the working group to check what we have there in terms of the main definitions, the overall framework, the different coordination models that are considered. And please provide your feedback so we can address and refine as needed. So what do we change? So going section by section, in section two terminology, we added two definitions. We already had the domain controller, hierarchy controller that was in zero zero version, but we added a new couple of definitions regarding emission control. And basically, the concept that if we have multiple domains, we have to do emission control over all the domains that are involved as part of the multi domain emission control process. That should be coordinated across all the domains. And we also added something regarding the time bounded queue mechanism. So we are using those type of mechanisms. We also need to have what we need to coordinate or synchronize within domains in order to use those mechanisms. These terms are they're defined, but they're used consistently in the sections, for example, in the new extended, well, new extended, the extended functional requirement sections and also in the section 5.2 where we deal with resource management and emission control. As I mentioned, two new requirements have been added. There were five in zero zero version that remained the same regarding budget allocation, capability advertisement, end to end path composition, and support for both coordination models. But we added a couple of requirements. One regarding that emission control must be coordinated across domains, as I mentioned. So an end to end flow must only be admitted if every traverse domain admit its second. And also for the time bound that the queuing domain controllers must be able to exchange information to align the cycle slots and their phases at the domain boundary. The problem statement per se is unchanged from zero zero version as this already motivated the two coordination models. Then section five dot two has been renamed and expanded. So we came from resource management to resource reservation and emission control. And here, we basically have addressed or have included what we have in the new functional requirements and in the terminal section that is the part about the emission control and the part about the mechanisms between domains for the time and then queuing queuing scale. We just discussed the framework level. So specific protocol solutions are left for future and for other type of documents. So that's also something that we wanna clarify. These are framework documents. We are not going into specific concrete solutions. And then going to the next to the last slide. So these are the questions for the working group and next steps. As I mentioned, we would like to get feedback. So for example, the core framework domain definition, product statement, the coordination models didn't change from zero zero version. That doesn't mean that it's complete, but we would like to actually get some additional reviews and some feedback even if the feedback is, okay, we believe this is complete. Or of course, if you don't believe it's complete, needs to be amended, changes updated, please let us let us know. The same thing about the domain scope, any remaining cases that should be considered. And once we get to that point, whether there is interest of in working on solution, but that will be a next step and not actually part of this specific document. And I see that there are some people in the queue.

[00:54:18] **Lou Berger**: It's working now.

[00:54:19] **János Farkas**: It works.

[00:54:24] **Jeong-dong Ryoo**: Thank you, Carlos. Could you go back to the terminology page? I have just one minor comment. Yep. Yeah. Actually, we have seven suitable categories categories. Right? One of them is one of them is time bound time bounded solution, which are not periodic. Okay? An example of such a solution is the Shoufu's in time EDF. So it has the left bound. It has a right bound. So it is time bounded, but it's not a slotted. Okay. So, yeah. Okay. That's mine.

[00:55:07] **Carlos J. Bernardos**: Okay. Okay. Thanks. Thanks for the comment. Yeah.

[00:55:12] **Lou Berger**: I'm actually next in

[00:55:13] **Speaker 5**: queue. I

[00:55:16] **Lou Berger**: appreciate the new terminology, but we I think you need to be careful not to re redefine existing terms.

[00:55:23] **Luis Miguel Contreras**: Okay.

[00:55:23] **Lou Berger**: So in traffic engineering and that that architecture, in both of those architectures, there's admission control and I think resource reservation are well defined. K. And I think the way by please just reference back to those and make sure your definitions are aligned.

[00:55:43] **Carlos J. Bernardos**: We'll check and add references to the documents. And in case for completeness, we can keep at least definitions. But ensuring that is the same that is in the Yeah.

[00:55:51] **Speaker 4**: I don't

[00:55:52] **Lou Berger**: if it's almost better to say for this definition, go read here.

[00:55:56] **Carlos J. Bernardos**: Okay. Without without yeah. Okay.

[00:55:58] **Lou Berger**: But that that's a little bit of a style point. That's my style. But if you do repeat it, make sure it's verbatim.

[00:56:05] **Carlos J. Bernardos**: Yeah. That's for sure. We should be consistent. And then I'm I find either way I prefer sometimes to repeat just for avoiding going back and forth, but I find either way.

[00:56:13] **Lou Berger**: Don't paraphrase then.

[00:56:14] **Speaker 5**: Just copy and paste. Yes.

[00:56:15] **Lou Berger**: And say from here, this is the definition.

[00:56:17] **Luis Miguel Contreras**: Sure. Thanks.

[00:56:20] **Mike Johnston**: Thanks. Hi. Mike Johnston. So just a clarification question because I I couldn't find the discussion about the domain definition in the mailing list, but maybe I'm not looking for it right. So by multi domain, you mean multi domain controller within a single administrative domain. Is that correct?

[00:56:40] **Carlos J. Bernardos**: At this point, we have three definitions of domains Yeah. In the document. One is like administrative domain base.

[00:56:45] **Speaker 5**: Mhmm.

[00:56:46] **Carlos J. Bernardos**: One is technological domain, and the one that actually we are following is based on controller. So we understand a domain as something that is under control of a PC, for example, or whatever. We don't go into that PC specific solution, but that will be an example. That's what we have in in the document. And this is what we understood is the consensus from the working group. Yeah. Okay.

[00:57:04] **Mike Johnston**: Great. I found one or two places where it's a little bit unclear, I'll just drop you an email for it with some suggestions.

[00:57:09] **Carlos J. Bernardos**: Thanks.

[00:57:12] **János Farkas**: So any further Yep. Yeah. Go go. Yeah.

[00:57:17] **Luis Miguel Contreras**: You have not finished. Okay.

[00:57:18] **Carlos J. Bernardos**: Yeah. So, yeah, that's that's all basically. Again, the authors, we will welcome any additional feedback contributions. That will be very much welcome. Thank you.

[00:57:28] **János Farkas**: Any further feedback right now? Nobody in the queue? Thank you.

[00:57:57] **Speaker 13**: I'm I'm from Ericsson, and I would like to give you some update about our draft, which is deterministic networking SRv6 data plane for service protection. Since the last meeting, we have work group adoption. And the draft is about how we can do how we can leverage existing IPv6 and SRv6 encapsulation to have a redundancy seed. And we also want to leverage the traffic engineering capabilities of SR v six to that. On the mailing list, there was a question for us. Are there any implementation available? So we we actually have two implementations of this draft. One of them is the dependable networking toolkit. It's a result result of three years of hard hard work by a small team with within our company and the university collaboration, and it it's basically a generic way to our routing router and switch, and it support many type of encapsulations and protocols, including lay in layer two DetNet and in layer three MPLS DetNet data plane. And as addition, we implemented the in that application as well. You can run it pretty much every, let's say, in the past five or ten years Linux, so it's very portable. We have no external dependencies, and it was it was a design decision from the beginning. The second implementation is XDP FRER. This is a high performance TSN FRER implementation, or this is started as a high performance implementation, but we also extended it with the redundancy support. So it's used XDP layer of Linux packet processor to create the redundancy And use the SRV six routing of Linux to create the disjoint passes. The next steps, the technical content of the draft is stable and is in line with the spring document. There's related spring work group document about the redundancy protection algorithms algorithms and and the end behaviors and end cop behaviors. Comments and contributions are always welcome. And some further work item candidates we we think of are description of the redundancy data as designed for DetNet scenarios, details of redundancy policy, DetNet cases like how we can encode encode the the redundancy function in the redundancy seed. We have some proposals, but we it's we have to need to discuss that. And additionally, how we can work together with existing SRv6 deployments like, for example, SRv6 based layer two or layer three VPNs. And thank you for the attention. If you have questions, I'm here.

[01:01:46] **János Farkas**: Any questions, comments? Okay. Thank you.

[01:02:14] **Speaker 5**: Yeah. Good afternoon, everyone here. This is the draft that's being presented quite a few times. This is a fifth version. Well, this time, I'm just going to present the difference. Well, basically, the the changes based on the comments from the previous few meetings. And then now the first one is the subject line of the draft has been changed. Well, this is based on the comments from and also from a low last time to say, okay. This draft is more like a framework. So, basically, in that case, we change the subject line to be the framework for flow and aggregation in scaling determinist network. Our original label, there is a line at the bottom of the page showing, okay, what's the subject line before. Yeah. Here, just to say, okay, what changes from zero four to zero five? And then the first two bullets just give some histories and also appreciation to many come review our comments. This time, there are six major changes. The first one is has as I have as I said already, it's about the the title and the revised introduction. And then the second one is regarding one subsection, actually, to clarify the motivation for the draft. And the third one is regarding the the comments, what it's like and the the relationship regarding the forming mechanism. That is the comments from last time also from chairs and also from pollers. And also to add contents, the fourth the fourth one to clarify the data plan formats and the control plan extension considerations. And then regarding the fifth one, there'll be other major control and the resource allocation for aggregate. And the the the final, like, editorial change to to move a sanction to all the app app apex. Okay. Well, this is just the the diff comparison. Well, there are thick bubbles on the right part, and then that that bubble each bubble is corresponding to a change that's been displayed in the previous slide. Yeah. This is the the first one. This is based on comments, and then we changed this one. Okay. This is a framework. And, also, in the introduction section, we provide detailed objectives. Basically, it's okay. When you read the introduction, you're going to know, okay, for this framework draft, what are objectives here? So one thing we want to emphasize, this this draft is to focus on the flow aggregation in scaling DanNet. It's not going to replace but to complement existing DanNet DP specification, like IE, RFC in September and in September. Are those the next three objectives? Now I'm now going to talk the details just in the draft here. And the second change. The second change is regarding some comments on the following mechanism that that well, basically, the data plan. But this is in general because the comments from last time is okay. There are quite a few different foreign mechanism or queuing things, but how about this one? And then so based on the comments we consider, this one will be like a starting document in general to talk about the following mechanism mechanism regarding the aggregated flow versus member flows. And, also, in the the the new change, in the new revision, we put one example on the c score and n score to demonstrate the benefit of flow and aggregations. Yeah. That is the change. And then this one is regarding the data plan format. This is also comments from the last time to say, okay. What are you going to specify to achieve in this draft when compared to some other draft or existing work? So here, we just to make it more clear, like aggregation information can be used alone or together with some other metadata to get a queuing and a forwarding. And then we list some data plan format, the encoding format for data plan or the a different a bunch of options, like in the some traditional ex like, existing like, DSAP, our traffic classifier, our a label in our state eighty nine sixty four, something new. No. Sorry. Some existing one and also the MPS M and A things there. The last one is has now been standardized or adopted, but this is one alternative option for the for the extension of the DPU format here. Yeah. Here, we want to emphasize the framework, the framework of draft. Our framework draft is focusing on the extension of the DP to handle the aggregation, to to handle the aggregated flow with with also with the consideration of individual flow. So that is the focal point of the framework draft, our draft. And this one is regarding about the automation control and the resource allocation is also with the focus on the DP. But the with the consideration here, it's the automation aggregated level automation also will have to ensure the guarantee for the individual flow. So they say for the admission control and also to for the re resource allocation. So for each one, admission control and the resource allocation, you know, both the aggregate level of flow and in individual or member flow requirement have to be taken care. Yeah. This is just for completeness. And then we say, okay. Well, in it cost, you know, for the draft. And then there are more things on the control plane thing that that need to be considered. For example, well, this is the first bullet regarding the network parameter and end to end budget, the exchange across the different domain controllers. This is like a reference Carlos. I think he just presented on this part. And the other thing, we are referencing another draft, individual draft to see the flow aggregation while there needed some mapping. But when the that flow then that flow crossing across all domains over one TSN stream, you know, those type of things. Well, We talk about something need to be considered for the control plane extension. The details. Now the details are in the the draft, but still we have to emphasize the draft is is to focus on the DP part, data plan. But the CP, we cannot exclude it. So, basically, we are adding words on the sections to to describe or to explain. Yeah. That is the the things we collect all the comments from previous a few a few press meetings and believe as of now, we have taken care of the comments. And then now, you know, we want to, of course, continue comments on this one and, yeah, to work. It's good.

[01:10:09] **János Farkas**: I have a question to page seven. If you could go back one page on can you go back one page? On the bottom bullet, like, net flow to TSN stream mapping. I thought this is the case when TSN is a subnet technology. So you have the DetNet flow and TSN as a subnet. I am not sure on the use of BGP here or maybe I don't get the use case.

[01:10:40] **Speaker 5**: Oh, you mean that sorry about the the resonance is so bad.

[01:10:44] **Speaker 4**: I

[01:10:44] **Speaker 5**: just cannot clearly clearly hear it, but I I assume you're talking about a segment bulleted regarding, like, a this is also like a cross domain here. You have a DATNA flow domain. You have another DATNA domain. And then you have a flow that are going to that net flow going to a path, well, whatever from the left, that net domain, like the the domain one, and then go to the the the other domain two. But here, in between, you have some other, like, TSN domain or whatever things you need to map.

[01:11:20] **Luis Miguel Contreras**: K.

[01:11:20] **Speaker 5**: Yeah. And then this side is mapped to TSN, but to the other side, the TSN map out. Yeah.

[01:11:26] **János Farkas**: Yeah. Maybe take this offline. Any further questions, comments?

[01:11:34] **Lou Berger**: Yeah. I think was asking about the appropriateness of using BGP to

[01:11:38] **Speaker 5**: specify Oh, okay. Sorry.

[01:11:39] **Lou Berger**: Oh, yeah. To specify what's happening at the TSN layer.

[01:11:43] **Speaker 5**: Oh, okay. Okay. Yeah. And and yeah. No. No. I understand. Okay. Because the resonance, I just cannot

[01:11:47] **Lou Berger**: Yeah. Understand.

[01:11:48] **Speaker 5**: Yeah. Yeah. Yeah. For the this is just to try to give an example. We reference the draft that also authored, know, one of the co author, about how to well, we can use the got this in, like, a consideration for the CP, the CP parsing. So, basically, we well, in that draft, we say, okay. We can use the BGP flow spec to handle these type of things Because, you know, this draft our draft is talking about the cross domain things. The cross domain is going to unless there are different scenarios, like, you're always running on dead net domains all the way. But also, you have some other scenario. You have islands of DetNet domains with some other, you know, domain in between. Or in that case, we want to use this.

[01:12:35] **Yunchao Liu**: Thank you.

[01:12:38] **János Farkas**: For the thoughts? We have further thought

[01:12:42] **Speaker 5**: about, you know, the thing, and we try to, you know, collect all the comments and work hard. Yeah.

[01:12:49] **Lou Berger**: So as this is Lou as contributor, not chair. So I've got them on the floor. It would have been helpful for me to look to understand how you're mapping how you're working out aggregation across our current Yang models. Because in the Yang's definition, we have support there's envisioned support for aggregation. And if you remember the work, we spent a lot of time on aggregation. And I'm I don't think you mentioned that in the document. No.

[01:13:22] **Speaker 5**: No Yang model.

[01:13:23] **Lou Berger**: So I think bringing looking at the-detnet-yang model and talking about how it supports aggregation would be helpful would have been helpful to me as reader.

[01:13:34] **Speaker 5**: So your suggestion is to add something regarding the young model.

[01:13:40] **Lou Berger**: So You know how you've aligned you're trying to align with what's happening at the data plane level?

[01:13:45] **János Farkas**: Mhmm.

[01:13:45] **Lou Berger**: It would be helpful also to align at the at the Yang level. If you haven't looked at it, I think looking at how aggregation is supported there would be helpful. Okay. Yeah. And, again, this is a this is a comment as contributor.

[01:14:00] **Speaker 5**: Sure. Okay. Yeah. We can take a look, but still, like, seems like our focus on the DP part. Yeah.

[01:14:06] **Lou Berger**: So the Yang model was designed to support the data plane.

[01:14:10] **Speaker 5**: Okay. Yeah. Yeah. But okay.

[01:14:11] **Lou Berger**: You know, it's all about setting up the data plane.

[01:14:14] **Speaker 5**: Okay.

[01:14:15] **Lou Berger**: Sure. So it should be well aligned. I I would almost expect an informational document on aggregation to describe how to use the Yang model to control the data plane.

[01:14:25] **Speaker 5**: Okay. Oh, yeah. We we can take a look at that.

[01:14:29] **Lou Berger**: Take a take a look and and then see. Just a contributor contract comment. If you don't agree, don't do it.

[01:14:35] **Yunchao Liu**: Okay. Cool.

[01:14:35] **Speaker 5**: Yeah. Sure. Thank you. But as a chair or something else.

[01:14:42] **Lou Berger**: We'll we'll see how it develops in the working group. Thank you. Hello,

[01:15:00] **Xiaofu Ji**: everyone. I'm not sure if you can't hear me clearly. Hello?

[01:15:08] **Lou Berger**: Yes. The acoustics aren't great. We're getting a lot of echoing, so maybe speak a little quieter if possible, and maybe that'll help.

[01:15:25] **Xiaofu Ji**: Okay. This is. I will present the the proposal for mechanism to control data caused by ingress shaping. Okay. There are several updates in this version. Firstly, we'll be factoring the section introduction to reflect the the motivation of this proposal. Policing is a collective term for a series of actions, such as reshaping action and nonconforming parties that exceed the expected traffic specification. It's important that the the only when the packet input into the cooling mechanism is conforming, it can provide a bounded deleted of the the past. The queuing mechanism cannot control how long the increased shipping delay. Secondly, we changed the term polishing delay to shipping delay to avoid the confusion and also change some related terms. For example, the head and the policy delay is changed to increase shipping delay, edge to edge policy delay budget to shipping delay budget, and under point timing delay is changed to egress timing delay. Again, this figure shows the relationship between the policy and the query function. A nonconforming flow is transformed into conforming flow and then enter the data pass. The and and no delay requirement of the service flow equals to the pass delay plus the shipping delay budget. The pass delay is guaranteed by the crew magazine. The shipping delay budget equals to the ingress shipping delay plus the ingress dumping delay. And the Egress dumping delay is carried in the packet used as the holding type and the Egress to remove the jitter caused by the policy function. So the saving delay budget can be set for the service flow according to its possible maximum saving delay experienced on the network entries. It may reach the order for magnitude of SPI. For example, a nonconforming arrival pattern may contain too much packets arrived back to back during SPI. The last packet in the block get a large shipping delay. It may also be a small one based on the sampling or configuration. For example, the application source control the flow flow flow rate to fully comply with the traffic specification and the solution traffic per API. Anyway, a smaller budget is better. So this figure shows how the nonconforming arrival pattern is changed to conforming shape of the pattern after the policy and fabric network entries. Three, closing packets are subversively distributed with the SPI. The cooling mechanism is expected to apply the same latency and JIT to these three packets. And, eventually, g s three packets are once again closely together and network ablaze by the dumping function. So from one to one consideration, if our tenant passed advanced multiple technical domains, there are two options to apply policy control. The first option is to apply separate policing for each domain. The second option is to apply single policing for all domains. The first option is we introduce more shaping delay convalescent space of pass delay. Especially considering that the easy transit domain and the equals domain, either we save a conforming traffic from the upstream domain. So so so so the it is a mini lease to turn the originally conforming output of traffic into nonconforming traffic by a dump and then turn it into a conforming traffic by. So this is mini news. So by comparison, the second option is the button. Okay. Thank you. For next step, we welcome any comments and comments and questions for this approach and any interesting for cooperation. Thank you.

[01:20:44] **Jeong-dong Ryoo**: Chino, please. Thank you, Xiaofu, for the presentation. Yeah. I remember I have, exchanged the emails with you about this draft, but my question is a little bit different on now. Could you go back to the page two, overview of the solution?

[01:21:06] **Xiaofu Ji**: Okay.

[01:21:08] **Jeong-dong Ryoo**: Yeah. Thank you. It's page three. So you assume that the end to 10 latency requirements is is larger than the past delay. Is it correct? Yes. So how can you can you guarantee that? How can you guarantee that the path to delay is less than the delay requirement?

[01:21:44] **Xiaofu Ji**: You might if I understand correctly, the the requirement of under under delay of a specific service flow is predetermined. Okay? Then when we can see the the possible maximum shipping delay on the network entries. So the requirement of the delay will be the pass delay. So based on this pass delay, we calculate the definite pass.

[01:22:28] **Jeong-dong Ryoo**: So if I understood correctly, you assume that there is a certain mechanism that can guarantee such a path delay is less than the delay requirements?

[01:22:41] **Xiaofu Ji**: Yes. Sure.

[01:22:43] **Jeong-dong Ryoo**: Okay. It is assumed. And your draft is not covering that part. You're talking about the ingress shaping delay, ingress stamping delay, and some of those delays can be exactly as the delay requirements. Okay. I understand. But as I have I have told you in the previous meeting and maybe two meetings before, this this kind of solution. I'm not talking about the motivation or the necessity of the solution, but the mechanism itself is quite overlapping with the existing standard. I I told you the exact number of the standard. Have you looked into that standard?

[01:23:38] **Xiaofu Ji**: I yeah. I maybe I don't remember clearly about you suggest document, but I just remember that you draft the 18 mechanism. Maybe you have some same content with the Right.

[01:24:01] **Jeong-dong Ryoo**: Right. That solution is mentioned in the ADN draft and and another ITU-Ts standard. I will tell you more about it later to you, and I recommend you to look into that standard. Thank you.

[01:24:20] **Xiaofu Ji**: Okay. Thank you.

[01:24:24] **János Farkas**: Okay. Thank you. Let's move on to the next one.

[01:24:48] **Speaker 4**: Good afternoon. I'm from China Unicom. Today, I'm going to present our work on handling of traffic characteristic division for DetNet. This draft was presented at IETf-one hundred twenty fourth meeting. We highly appreciate the comments from Gino, Yanosh, David, and Lou. Based on these comments, we have made some updates. We have changed the draft name and terms, replaced the anomalous traffic with traffic characteristic division to avoid misleading. As pointed out by the Gino and Yanos, it's not a flow, false, or errors. Second, we clearly state the problem, specify the gap between the dead night audio model and the practical deployment divisions. We especially focus on the macro burst accumulation at flow aggregation points. Third, addressing the comments from the David and Lou, we clarified the applicable scope to periodic queuing mechanism as defined in data plan taxonomy draft. Well, let's look at the background. As we know, the data relies on the results reservation to guarantee the bonded latency, the low jittery, and low packet loss rate. In ideal data model, each flow strictly conforms to control plan scheduling. The fine grained admission control and per hop traffic shaping up keeping keep all traffic within the reserve time slot capacity even at aggregation nodes, but it is quite difficult to achieve in practical deployment. There are three memory many reasons. First, the soft traffic has a variable packet lens and even arrival time, it will generate the macro burst at egress queues. Second, the admission control is caused. Now yearly use the second level average bandwidth, but it fails to capture the macro burst in millisecond. Third, at the aggregation node, multiple flows share egress and their macro burst will overlap. It will exceed the reserved capacity. As we can see on the below figure, it's a comparison of the normal scenario and the deviation scenario. The packet with the label one use q one should transmitted in the time slot one. But due to these above reasons, it it sometimes will will exceed the time slot capacity, so it will break the arranged schedule. How do the current solutions solve this? We've met we mentioned the deviation problems. On the control plan, the method using the permission, the reduction of results based on the peak traffic. On data plans, we'll directly discard the packet exceed the time slot capacity. All the buffer will will our buffer it onto the nice scheduling circle. However, this has limitations. It will lead to the low results utilizations, the save severe queues decorations for affected flows and the performance may even worse than the BE service. So we propose and enhance the data plan mechanism to gracefully handle the transcend traffic deviations. Our mechanism included two complementary policy, squeezing policy and degrading policy. The policy activation rules and threshold can be configured by the controller, and this solution is compatible with the existing periodic queuing mechanism. It can ensure the priority for the data flows, and it can provide the graduated response based on the deviation severity. For the co handling policy, squeezing policy temporarily differs deviated package to the nice time slot for transmission. While retaining original scheduling identifiers, this provides a temporary capacity expansion to avoid data loss during the transist burst. And the degrading policy directed evaded parquet to a lower priority queue and modifies the scheduling identifiers when accumulation exceed the preset threshold. So these two policy can be enabled independently or concurrently. If both of them disabled, it will fall back to the default mechanism, discard or just to treat as a BE. Moreover, we also introduced the c c two safeguard mechanism to prevent m bonding accumulation caused by consecutive squeezing. The way it's a synchronization threshold mechanism. After n slowed squeezing, the current queue must re synchronize the with the time slow schedule to keep consistent. And another is exponential decay mechanism. The loud squeezing capacity decay need to decay exponentially when there is a consecutive squeezing. So this will leak limit the degree of the squeezing. So we'll it will avoid to affect the redefined deterministic schedule. Finally, there is a overall traffic division handling logic. It has four steps. Step one, detects the traffic division. When packet arrive, the node checks whether the time's load is exceed. Step two, make decision. If they're to make a decision to to check whether we need to use our proposed solution or just normal forwarding. Step three, execute a specific policy using either the policy or the degree degrading policy or use both of them according to the decision result. Step four, report a result to the controller for net worldwide coordination. Okay. For next steps, we are asking for more reviews and comments from the working group, and we will keep alignment with the net net data plan mechanism. Thanks for your attention, and sorry for my hoarse voice.

[01:32:17] **János Farkas**: Juno, please.

[01:32:21] **Jeong-dong Ryoo**: Thank you. Thank you for the nice presentation. I have a I have a rather general question about this draft. I agree to you that, there can be, burst accumulation. And because of the burst accumulation, the flows, a T SPEC, traffic specification, can be changed over hops or over domains. So in end attended past, the bad things can happen. So I agree to you that there can be something must be done to to adjust those mis misbehavior. Okay? But if you think about who who is the cause? What is the cause of those misbehavior? It is not the flow itself. It is the rather a network. So because of such a background that we have to isolate flows, we have to protect flows, and we have to guarantee flows performance over other competing flows. But in general, your two solutions, squeezing and the one yeah. The the the other one. I think screeching or degrading can cause innocent flow can be penalty penalized because of other flows, bad behavior, innocent flow can be penalized. So I think we have to be more careful about also isolating flows from receiving flows and so on. So I suggest you to consider more about this aspect, and I myself will think more about it. What do you think?

[01:34:37] **Speaker 4**: Okay. Thanks for your suggestion, and we will consider it. Yeah.

[01:34:43] **Jeong-dong Ryoo**: Okay. Thank you.

[01:34:55] **Lou Berger**: This is Lou as contributor. How do you see squeezing and degrading relating to shaping and policing?

[01:35:06] **Speaker 4**: So you are asking the shaping policy. Yes. If but the current problem is that both the admission control, it you you only use a car. The not use some some device don't use the shaping. If it can do well shaping, yeah, the all the flow will strictly conforms the control plan scheduling.

[01:35:34] **Lou Berger**: So you're saying that the these terms are equip are for admission control only?

[01:35:43] **Speaker 4**: For what? Pardon? For me?

[01:35:45] **Lou Berger**: It's for accounting for the shaping that happens in the network, in the data plane. Is that what you're saying?

[01:35:51] **Speaker 4**: No. We we our solution is to solve the that's the the temporary, division, and it won't affect the overall data schedule in a very temporary camp, just to gracefully, gracefully solve it.

[01:36:26] **Lou Berger**: In the data plane or in the

[01:36:28] **Speaker 4**: In the data plane.

[01:36:29] **János Farkas**: Okay.

[01:36:29] **Speaker 4**: Also but the control plane need to do some Like coordination I need to reset.

[01:36:35] **Lou Berger**: That makes sense. Okay. I'm trying to understand if the term is any different than shaping being applied to a time slotted network or time slotted queuing. Excuse me.

[01:36:49] **Speaker 4**: Pardon? What's the question? Sorry.

[01:36:52] **Lou Berger**: Is squeezing any different than shaping? Or is it a special case of shaping when it is applied to time slotted queuing?

[01:37:03] **Speaker 4**: Yeah. It's the if you use the shaping when in the if you use the shaping, that it can buffer some deviations. Yeah. It but if there is no shaping, just the car or just to use the car, the it has the problems, so you can use the average quasi and gradient solution to avoid some division.

[01:37:35] **Lou Berger**: I'll I'll take it to the list. I'm not sure I follow. To me, it seems that you're introducing a new term for something that we already have a general term for. I don't understand why squeezing is different from shaping, but I'll I'll take it to the West.

[01:37:53] **Speaker 4**: Okay. We can chat on the

[01:37:54] **Lou Berger**: Or offline. Yeah. Yeah. Thank you.

[01:37:56] **Speaker 4**: Thank you so much.

[01:37:58] **Carlos J. Bernardos**: Thank you.

[01:38:01] **Taesang Choi**: Luis.

[01:38:13] **Luis Miguel Contreras**: So hello, everyone. This is Luis from Telefonica. Will introduce this this new draft, which is about observability capabilities for pre auth and and also the proposition of some requirements associated to that. So the idea basically is okay. Pre office is fundamental for the reliability functionality. So, basically, as as we well know, PREOFff allows the replication, the elimination of the ordering of the of the packets once we deliver through different paths. But, however, there is no notion of operation as operation and maintenance associated to the pre op functionality. It's true that there are OIM mechanisms for the net service and so, but not for specifically for the pre op function. So here, the the the idea of this draft is essentially to work on that. So define PREOFffer specific OIM requirements, metrics, and and so, and basically identify the set of the ends that could be worthy to be reported so that we can incorporate this operation on top of pre auth.

[01:39:17] **Mike Johnston**: So

[01:39:20] **Luis Miguel Contreras**: so, basically, the the idea was I said, okay. With pre auth, have this replication elimination and ordering but it would be nice to have the possibility of understanding what is the behavior of this pre op once it's running in the network. So, essentially, to understand how pre op decisions are made, which path copy is selected at the time of once we have a copy of the of the different flows, why you say oh, what is the path that we have selected and what others are discarded? Also, the reason why the packets are discarded and maybe some further details about how the reordering reordering buffers behave, what is the depth of the buffer, and these kind of things. So in in the draft, we are proposing some initial ideas, of course, hoping to to be discussed and and basically to receive feedback from the working group. An initial list of observable events that could be maybe relevant for for the operation of pre op will be the to understand the the replication events, the duplication the duplicate elimination events, the reordering events, also the timeouts in in case that we don't receive any copy for any of the past to to understand, yeah, what what are the the demos there, the cap detection events, and late arrival events. So regarding metrics, we also introduced some initial ideas. Of course, this is open for discussion as well. And we could identify four set of of metrics. Replication metrics as could be the number of replicated packets. Elimination make metrics as could be the number of duplicate met packets that are received, also the duplicate packets discarded, and so on and so far. Reordering metrics like the number of reorder packets, the average and maximum reordering in-depth because we will have some buffer to play with and and basically to understand what is the depth of the reordering, one, two, three n packets, and also the average maximum holding time for the reordering process. And finally, some reliability metrics like the number of recovered packets. So all of this will help us to provide an idea of how the PREOFff is behaving in the network, the PREOFff functionality. We introduced as well some some requirements. Once more is our first try, so we know that this require more and more discussion. And these are six requirements we have the enterprise so far. Requirement one will be to expose count counters associated with packet replication activities. Require requirement two, expose counters associated with duplicate elimination. Requirement three will be for the support of the of of identification of packet discount reasons to understand what will be the the reason behind the the discarding. Maybe the packet was already received, the packet arrived late, and so. Requirement for exposed reordering buffer utilization statistics to understand the behavior of the buffer. This will help us to fine tune maybe the behavior of the of the buffer so that we can optimize it later on for for the purposes. Requirement five, the support of time stamped reporting so that we can track basically when when the things are are happening. And requirement six requirement six is just simply to to reinforce the point that these requirements will remain independent on the underlying the net data plane technology. So, basically, that could should be data plane agnostic. So the next steps is because this is the the first occasion that we've introduced the the draft to understand if the this pre office specific observability is something of interest for the working group to to to check if it's basically a a gap. We agreed on that. And, of course, to request feedback to collect as well ideas. So all all about metrics, all about the requirements, about events as well as our first try. So, yeah, basically, I would like to invite interested people here in the working group to, yeah, to basically provide comments, suggestions, and feedback. My idea is to prepare a new version for next ATF, consolidate all all the feedback received, and and keep working on this and and basically entering maybe into details of a specific requirements and and so. That's all from my side. Thank you. Thank you. Thank you. Balázs

[01:43:44] **Balázs Varga**: Varga from Ericsson. Thank you for the presentation. I I have first a clarification question. So I had the feeling that so first of all, I I think it is very important to understand what happened inside those functionalities. And we we we should have feedback from that. However, so far in the that network group, we have not defined the algorithm used for replication elimination. We have defined what you can see on the wire, and there are some aspects defined for that. My feeling is that based on your requirement list, that it is very much algorithm and implementation specific. Some of them maybe not, and I think this is something that should be the first focus if we decide to to go on that part. But but some of them is definitely very implementation specific. For example, there are implementation where you will not know if a packet arrived over which path it was received because it has the same flow identifier, for example. So some of these might not be a valid counter or valid state in some of the algorithms. In some others, it can be. So I I think that should be discussed first whether there is a gap, but we are just jumping over and and trying to define something that was not defined before.

[01:45:19] **Luis Miguel Contreras**: Okay. Thanks, Balázs. Maybe it could be, as you as you said, maybe some of them could be could have some some some dependency on the algorithm. Of course, we we can discriminate them. But, yeah, things like maybe understanding what is the path where you are receiving the the traffic and so could be relevant for maybe to detect any kind of issue on the path. So maybe we can work on on, let's say, on the boundaries to clearly define what could be algorithm agnostic, but irrelevant to to to be reported. Maybe it's a matter of understanding the the, yeah, the actual operational events that could be maybe worthy to to to get evidence from.

[01:46:00] **Balázs Varga**: Okay. Okay. Thank you. And and the second question would be about we already have an OEM document. So how this document is related to the OEM related documents? That would be my question.

[01:46:18] **Luis Miguel Contreras**: So it usually leads with with the overall OEM, do mean? Well, I guess that the scope of the other the the OAM document is on the service itself, not on the functionalities. I'm not sure it would make sense to bring this content there. Maybe it's it's a matter for the chairs to decide. But but, basically, what we are intending to cover here is the the gap of this functionality. It it makes sense to put together with the other document. Okay. No. I'm not against that.

[01:46:52] **Balázs Varga**: I I I think that relationship should be clarified just in order to avoid later on any dissonance between the the the drafts and and here just to define in detail the focus. That would be my my my request. Thank you.

[01:47:07] **Luis Miguel Contreras**: Okay. Thank you.

[01:47:13] **Lou Berger**: So I think your the requirements at a high level are pretty noncontentious. You know, it's gonna be easy to get agreement on. I think it's the details that Balaj is talking about in terms of implementation. There's definitely certain information you have listed, which I think will be very hard to do in any implementation. Mhmm. Sure. As an as a user, that might be interesting, but I I just don't see, for example, having your generated sequence number being captured when you're operating in a any reasonable data rate.

[01:47:49] **János Farkas**: Mhmm.

[01:47:50] **Lou Berger**: It's this you know, there's too many packets going on a second. It doesn't make sense to even capture that. So I I I think it would be good to break down what is actually required and what is desired information

[01:48:05] **Mike Johnston**: Okay.

[01:48:05] **Lou Berger**: As you refine the document.

[01:48:07] **Carlos J. Bernardos**: Okay.

[01:48:08] **Lou Berger**: And I think the point about general relationship relationship to the other OEM work makes sense, and I don't have an answer for it right now.

[01:48:16] **Luis Miguel Contreras**: Alright. Thanks. Thank you for the feedback.

[01:48:19] **Jeong-dong Ryoo**: Thank you. Thank you for the nice presentation and preparation. I have just I have just a quick question, not a comment. In your requirement three, it is about the identification of the packet discard regions. I'm not so sure what you mean by packet discard, not the elimination. And how can you identify the packet discard, the region of the packet? This is my question.

[01:48:52] **Luis Miguel Contreras**: Basically, there could be you could discard maybe a packet because it was not well received or just simply because you have other copies of that. Basically, to understand what is behind the decision of discarding certain packets. Maybe, as you said, probably in the context of pre op, maybe it makes not so much sense to consider all the reasons for discarding, just simply the the fact that the packet has been already received. I mean, there is one copy already. Maybe, yeah, maybe something we could revise. Yes.

[01:49:20] **Jeong-dong Ryoo**: Okay. So so it is different. Discard is different from elimination that you what you are talking.

[01:49:27] **Luis Miguel Contreras**: Yep.

[01:49:28] **Jeong-dong Ryoo**: Okay. Thank you.

[01:49:30] **János Farkas**: Maybe

[01:49:37] **Balázs Varga**: I I I just wanted to point to one more information. In in previous, already spoken about this open source implementation of the PREOF functionality. And in the user space open implementation, there are also some observability related functionalities. So maybe this is something worth to check. We can have also discussion on that offline. Of course. Because I I think that some of this stuff, maybe you you you will find similar in that that implementation already.

[01:50:10] **Luis Miguel Contreras**: Perfect. Wonderful. Thank you.

[01:50:12] **János Farkas**: Maybe just add on to that one. Like, this work here somewhat based on or was triggered, inspired by two two dot one CB frame application elimination for reliability, which specifies counters and so on. So if someone goes that way to implement the functions, that is some basis and that's also there in the code.

[01:50:35] **Luis Miguel Contreras**: Okay. Okay. Thank you.

[01:50:37] **János Farkas**: But it's good contribution, good discussion. Thank you.

[01:50:40] **Mike Johnston**: Thank you. So

[01:50:41] **János Farkas**: we have some time actually and we could not complete the discussion in c score. So I I would suggest to leverage the time and and and go back to the to the c score. And, actually, I would like to call out a specific slide that Gino kindly prepared for for this session. And I actually have a question I think maybe it might be beneficial to discuss given the people are in the room that back to the scope of the STOs and given that the work has been done, a lot of work has been done in the ITU study group 13 standards are out. And correct me if I'm not getting it right, but my view is that the actual functional and operational specification belongs to the ITU documents. And what is the ITF scope is the data plane details and pretty much it. So if we want to have a clean separation, might be that might be the line. Mhmm.

[01:52:01] **Jeong-dong Ryoo**: Yeah. Yeah. Think we should go to

[01:52:03] **Lou Berger**: the floor.

[01:52:06] **Taesang Choi**: Hi. Yeah. I'm the rapporteur of question six in ITU-T-thirteen. And do you mind just saying your name because Yeah. I'm I'm Taesang Choi. Okay.

[01:52:20] **János Farkas**: You can grab the mic.

[01:52:24] **Taesang Choi**: So so as as you just mentioned, I I think that's a correct direction that since in our group we are developing standards from the use case and requirements and framework architecture point of view. We don't go into the mechanisms and protocol level details. So if we can, I mean, the document that we are developing in ITU-T can take a role of baseline so that the hearing in-depth working group can further develop the mechanisms and protocol details based on that? I think that will be good harmonization between the two groups.

[01:53:17] **János Farkas**: What I just would repeat what I said before. We should avoid duplication.

[01:53:24] **Lou Berger**: What I thought I heard is you said you don't define the mechanisms and the formats. Is that correct?

[01:53:35] **Taesang Choi**: So far, we have dealt some part of it, but as an effort to avoid any duplications between the two groups. I think that you can sort out what has been worked on in in in our group. And then if necessary, I think that they can, the document can be further revised to avoid any any duplications between the two.

[01:54:07] **Lou Berger**: Yeah. We we we we very much wanna avoid any duplication. I I think we need to take a look at the liaison and see if it is clear on where you would where you are stopping and the IETf can start. And if it's not, perhaps that's what we do in our response to the liaison is ask for clarification.

[01:54:31] **Taesang Choi**: Okay. For example I mean, for your information, this document, although we were planned to consent at the last meeting, but we delay this until we get the response from this group. So if necessary, I think we can make any necessary revisions based on the decision made in this group. Okay.

[01:54:58] **Lou Berger**: That'll be good. Thank you.

[01:55:00] **János Farkas**: Mike, please.

[01:55:02] **Mike Johnston**: Thanks. Mike Johnston and it's great to see Tyson R question six rapporteur from study group thirteen here. And I would strongly encourage you guys to go and have a beer, coffee, your favorite beverage afterwards and to discuss this informally later because the at the moment, there does seem to be overlap and contradiction between some of these different documents such that liaisons are being sent pointing out that at a very fundamental level, one document mentions three pieces of metadata, another mentions four. Some of these we've talked about having two before. It seems to be a moving target between the two STOs, and it would be much better to have it consistent and and with much closer cooperation. And I think that will be really helpful. So it's great it's great to see you here, Tae Sung, and it's I think it would be fantastic if they could be closer cooperation.

[01:56:06] **Lou Berger**: Yeah. I I think the comment is a good one about having an outside conversation. So definitely would like to, you know, if you're available, spend a little time talking about it. In terms of the disconnect about two or three pieces of information, it's gonna be really easy. We don't own the base specification. We will not be defining something different. If it is, the IESG will not approve it. So it's gonna be that that particular point is easy. We're gonna do what the ITU-T document says.

[01:56:40] **Mike Johnston**: Sorry. Just to follow-up on that, we do have a problem now that if we if in this draft here, we are defining four pieces of metadata, we have to go back and revise those two completed ITU-T recommendations, thirty one twenty nine and Y.3148, because they only refer to three pieces of metadata. So it's there's like this

[01:57:04] **Lou Berger**: So if the ITU-T document refers to three, we're gonna refer to three.

[01:57:14] **Mike Johnston**: The three boxes on the top that says high level requirements, the box on the left refers to four, the two boxes on the right refer to three.

[01:57:25] **Jeong-dong Ryoo**: Could you could you go back could you go

[01:57:28] **Lou Berger**: That's not a problem we can fix here. That's not a problem we can fix here. So if if there's an internal inconsistency in ITU-T documents, That has to be fixed there, if we wanna use them. Yeah. The other alternative is we don't do the work here.

[01:57:51] **Jeong-dong Ryoo**: Yeah. Again, two important keywords. The first one is the alignment. The any related document should be aligned to have the exactly same metadata, same kinds of metadata, same number of metadata. That's for sure. The second keyword is non overlapping. K? So two, SDIO has a different aspect, a different document, different specifications. So, yeah, we are all working together to achieve those two two keywords. And as you can see in the future plan, they all will have full metadata. I cannot share with you. Thank you.

[01:58:34] **Mike Johnston**: Thank you. I'm very supportive of that.

[01:58:40] **Lou Berger**: Thank thank you. We definitely appreciate the discussion. We have maybe a minute and a half left in the session if anyone has anything they'd like to bring up in that time. Ah. We have a number of gaps in the notes. It definitely the acoustics in here, particularly upfront, are sometimes it's really hard to hear what everyone is saying. Please go back and check the notes. If you made a comment at the mic, please make sure your comment is accurately reflected. Please make sure your name is correctly spelled. We really would appreciate that. And with that, thank you very much for a good session and good discussion, and look forward to see you at IETf-one twenty seven.

[01:59:37] **János Farkas**: K. Thank you all.

[01:59:49] **Lou Berger**: Hello.

[02:00:34] **Xiaofu Ji**: 4.

[02:00:34] **János Farkas**: Right? Which is 8964.

[02:00:38] **Lou Berger**: It's definitely aligned with the data point.

[02:00:40] **Speaker 4**: Yeah. Yeah. Yeah.

[02:00:41] **János Farkas**: So from but this new

[02:00:43] **Speaker 4**: ID is to extend or to complement RC89