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

[00:00:04] **Tarek Saad**: We stayed up late, and my eyes are are shutting down as we speak, but I'm telling you.

[00:00:12] **Adrian Farrel**: Do you wanna share the first bit? Get us started.

[00:00:16] **Tarek Saad**: Sure. I can do that if you like. Are we all set? It's the top of the hour right now.

[00:00:27] **Adrian Farrel**: Yep. Ready to go.

[00:00:29] **Tarek Saad**: Okay. Welcome, everybody. This is the MPLS working group session in IETF-120. We have, the usual, faces for the chairs at the on the first slide, and, Mac is our secretary. Thank you for flipping the slide. The note, well, it's still early in the week, so please make sure you get yourself acquainted with this slide. It has useful information about participation at IETf as well as the any IPRs or, you know, rules regarding that. Please make sure we you leave time to go through this slide. It has useful information about participation in ITF. The next slide, please. The usual administrative information we share, the blue sheet is by now automatically generated, thanks to IETf. Couple of redirection pointers there. Importantly, with the minutes taking, we have a link that we shared in the chat. Please consider volunteering and notes taking if you can. We have a a page where we maintain the latest update about documents. Blue please do visit that and let the chairs know if there's any discrepancy in what you think about your document state is and, what is noted on that page. Let's move on to the next slide, please. We have a pretty packed agenda for today, around nine items last I checked with ten minutes each. So it's it's bringing a full full load for the session. Hopefully, the presenters are cognizant of the time slot they have. Please stick to that and and and be be kind of codeeous to the next presenter. Stick to your slot. Thank you. We'll move on to the next slide, please. I won't go over each one of them, but we're looking forward to the presenters updating us on that. Next slide, please. Okay. There you go. We have nine items. Next slide, please. We have a couple of erratas that popped up. One for RC5711. I think it's a ref a wrong reference that's being pointed out here by by Mikael. I think he the the there's a wrong reference. The the correct one is 3Dot1Dot7, but the the document is referencing 3Dot7Dot1. That's something we'll take with the AD. I think it's it's good to be corrected. Next slide, please. Another errata for RFD eighty six sixty three. It seems there is a mention of a p flag, and the intention of that p flag is the no PHP flag. The document itself, where we reference, where where the text is referencing it, I think it's RFC. Let me go back. I it's somewhere there, but, the the p flag has, there's two p flags in that RFC, and and the correct one that should be referenced is the new dash PHP flag. And I think that's a correct finger pointing there in the errata, and we'll have to take it up with the AD on this one as well. And we can if anybody has anything to share on this, Eratta, please come up to the mic as usual. Okay. We can move on. There's no noted liaisons outgoing from MPLS or incoming to m b MPLS. So that's a good thing. So we don't have to worry much about that. Now comes the the outcome of our, you know, of our work for the past period. We have delivered an RFC. I want to congratulate the working group on this milestone delivery. It is m and a related, and it's our first solution for m and a technology. So congratulations to everybody who contributed to this work as well as to the chairs and and the shepherd, as well as the authors, of course. And we can move on. We do have a document in the RST editor queue, so we're hoping it will progress in into a publication soon. Next slide. We we are productive, and we have multiple documents in ISG queue there, and some of them at different states. We do also hope they progress smoothly to publication. Next slide, please. We also have new working group documents. They are on the agenda for today, so we're looking forward to the presenters updating us on that. Next slide, please. We do have some updated documents. Some of them were presented before, but and some of them will be presented today. They are marked in blue color there. We have two of them on the slide. Next slide, please. Some documents, they're alive, and we're hoping they will stay alive. And, hopefully, we have a status report shared on the on the mailer on those. So these authors do keep the working group updated on those. And we don't have any recently expired draft, which is a good thing. Let's keep that. No individual new individual documents. Looking forward to those, coming in into our queue. And that's it. Ah, okay. We do have some individual drafts, that are on the agenda for today, and, we look forward to, yeah, the the presenter update on those. Next slide, please.

[00:07:31] **Adrian Farrel**: That's all you get.

[00:07:34] **Tarek Saad**: Okay. And by this, I'll I'll give you back the the ball for presenting the next set of slides.

[00:08:01] **Adrian Farrel**: Right. I think it's gonna be Haoyu.

[00:08:15] **Haoyu Song**: Good morning, everyone. Today, I'd like to report to the working group the progress of this draft and also discuss how we advance this draft to the next stage. Okay. First, let me recap some main idea of this draft. We use on-path telemetry technology to support network OEM. The basic idea including two basic masters, the postcard mode and the passport mode. So I o IOEM is a typical implementation of the passport mode, which means the packet header need to carry the instructions on what data to collect and as well as the data itself. Obviously, it has a a larger header overhead and also more complex data plane processing process. Another mode is postcard mode. There is representative master implementation is the IOAM direct export. In this case, the header still need to carry a instruction header to tell each node on the path what data to collect. So there's still some overhead involved. So the most cleaning ways just to carry a single flag in the packet header to tell the node to collect data. And on what data to collect, that is determined by the so configured through the manage management or control plane. So this idea has been realized in SRv6 using a o o flag bit in the SRH header. And so eight this draft is mainly talking about how we realize the same idea in MPLS data plane and using the MNA standard. So this slide show the high level diagram of the solution. We, in a network view, had a have a had a node and a node and the several transit node in between. The head node will Select the subset of packet to mark mark them to flag this packet to tell the other node. You if you see this flag is set, you should collect the configured data and send it to some remote telemetry collector. So the idea is very simple. It has several unique applications that the other modes cannot support. For example, using the this postcard mode, you can do the pass drop location that diagnosis. Because once the packet drop, you will note get data from the no data from notes later on in the past. But starting before the drop point, you can still collect all the postcards. So with this information, you can tell where the packet is dropped. Also, you just set the flag. You can trace the you can get the pass information at from the collector. It's very, very handy. Also, it's a the data collection process is decoupled from the forwarding process itself, which means it's will not intrude with the forwarding process. So with this flexibility, we can do a lot of things. For example, the security. We can afford we are afford to secure the data, encrypt the data before we send send them out to the collector. So that's a a more secure solution than other modes. So the key here is where we choose this flag. So we have to observe several limitations asserted by RFC nine nine nine four. The first thing is we we can we must avoid the forced 24 bits in the flag because those field might be used for ECMP. So you cannot change those space in the for the for the package that belong to the same flow. However, in this case, we because we want to just Select Select a subset of packet to trigger the data collection. We don't want to set every every packet. So we have to alternate this maybe this this bit, this flag in the packet. Thus, we have to avoid the first 24 bits. And the second limitation is we have to choose one bit reserved for the I e IETF standard use, note private, note experimental. So considering all these limitations, we we find the position bit position 42 is is ideal location for this what we call that a P-bit. So to support this action, we also had to set the action scope hop by hop. And, obviously, there's no any ancillary data.

[00:14:07] **Tarek Saad**: Excuse me. Would you like questions now or at the end?

[00:14:11] **Haoyu Song**: I'm all I think almost done.

[00:14:14] **Pavan Beeram**: Okay.

[00:14:15] **Haoyu Song**: So this slide summarize the main updates in this revision. We since we already have the this RFC nine nine nine four standard, we withdraw the figure to based on the requirement to be choose a choose a beat recommendation. And we also update the document reference to refer this normalized standard. And we discuss how we make it ECMP safety. Also provides MNA requirement and also the NAI definition in this document. So the MNA request is just a we need a one bit position, but suggest the value is a 42 to as is action flag. And the next step is certainly for the working group review of this signal format P-bit position encoding and maybe advance this drop to the working group last call. Thank you very much. Excellent question.

[00:15:27] **Greg Mirsky**: Greg Mirsky. Yes. Thank you. In your opinion, how this is different from IOAM direct expert?

[00:15:42] **Haoyu Song**: Can you repeat how, can you repeat your question? I didn't hear clearly.

[00:15:47] **Greg Mirsky**: Yes. How is it different from, IOAM IOAM.

[00:15:52] **Haoyu Song**: Oh, yes. In the first slides, I mentioned

[00:15:55] **Greg Mirsky**: Direct the Direct Export.

[00:15:58] **Haoyu Song**: Direct Export. D DEX mode is a this share the similar high level idea. But the DEX, you still need let the user packet to carry a instruction header to tell each node specifically what data to collect. So that's how what the dataset is determined at the head node. But here, yes, we only need a single flag to tell the node that you if you see this, it's triggered the data collection process. But, exactly on what data to collect, that's totally, that's a configure through other channels like management channel or config control plane.

[00:16:40] **Greg Mirsky**: I think that direct expert has

[00:16:45] **Zafar Ali**: more

[00:16:48] **Greg Mirsky**: capabilities than just one flag because it can direct not only that it's collected on a local node, but also the data is collected.

[00:17:04] **Haoyu Song**: Yes. There's a

[00:17:06] **Greg Mirsky**: different I think I I think that this is too little because you cannot control what data is collected.

[00:17:18] **Haoyu Song**: Yeah. The head node cannot control, but it's managed by the, you know, network controller. And this approach has some several unique advantages as which are summarized in these slides. Like, it's a support fully In

[00:17:36] **Greg Mirsky**: in that case, if you rely on a management plane to determine the type of the data you collect, then I'll have to ask how it's different from alternate marking method. Because alternate marking method can tell you on which packet to collect your telemetry, and the management plane determines what information you collect.

[00:18:08] **Haoyu Song**: Yeah. I I think AM approach has its own usage, its own use case and limitations. These are all complementary to each other. They have different application use case.

[00:18:21] **Greg Mirsky**: It seems that all the functionality that can be provided by this proposal already exists and available by other methods. Thank you.

[00:18:48] **Pavan Beeram**: Thank you.

[00:19:08] **Adrian Farrel**: Fabian, are you here or there? You're here. Right. Great.

[00:19:30] **Fabian Sowa**: Test. Okay. So I'm talking about our draft discovering m and a capabilities using LSP ping. Brief motivation. The current m and a RFCs, they all talk about m and a capabilities, but they consider their discovery as out of scope, as you see here in the references. So we need to find out what exactly are the M and A capabilities and how they should be discovered. I already presented the first version of this draft last year in Madrid. In the initial version, we proposed to use the IGP, like ISIS or OSPF, to signal the MNA capabilities through the network, and we got the working group feedback that the IGP is not the way to go for MNA signaling since it's a lot of flooded information in the network, which I totally agree. So, therefore, the most recent version now uses LSP ping for discovering those. You see that in the title change. We changed it from signaling M and A capabilities using IGP to discovering M and A capabilities using LSP ping. So two major changes, discovery and LSP ping. Beside that, the draft is nearly fully rewritten. We added discovery for post stack data solutions as well. We clarified the relationship to path Selection and a lot of other changes, like references, INR, and so on. So first of all, what do we need to discover? We have in stack MNA capabilities. That includes the Readable Label Depth, of course, the RLD, which is also contained in the IGP for now. It also includes the maximum NAS sizes per scope, which I call the maximum label depth, NAS, three values since we have three different scopes, and we need a list of supported instac network option action opcodes. The same principle applies to post stack M and A capabilities. There, we need to also signal if we can do post stack M and A at all. And we have various stack sizes, like the Readable Label Depth, including the size of the post stack header and the part, the offset between the bottom of stack and the post stack, we need to signal or discover the size, the maximum possible size of the post stack header itself. And, of course, we also need a list of opcodes for the post stack actions. When and how do we want to discover with LSP ping? So we assume that, first of all, the IGP does its thing. So a path is established without any MNA capability input, just as it is right now. Some coarse visibility can come from the IGP because there we already have the readable label that's defined in the RFC, but I think that just signaling the RLD is not enough. There's a lot more constraints from MNA that we need to consider. Once the path is established, the ingress node then probes the established path with LSP ping and learns the MNA constraints from that. That means the ingress node sends MPLS echo requests with the newly defined MNA capability query TLV along the path. There are two modes, trace out mode to reach all nodes on the path or ping mode to reach specific nodes, such as the egress, for example. Each node then responds with the MPLS echo reply, which contains the newly defined MNA capability response TLV, which then contains a list of sub TLVs with all the great capabilities. The ingress node then aggregates all the received responses and determines the path wide MNA constraints from it. If the constraints are not sufficient for our use case, we can adapt, like we can build smaller NAS if that's possible, we can resteer to probe an alternative candidate or another egress, or we can refrain and say, it's just not possible. We can't use MNA here. Okay. So here's the encodings of the MNA capability, query and response TLVs. For the query TLV, we have just one byte for now of flags. In that one byte, we have four bit flags assigned, two for ISD, two for PSD, and for each ISD and PSD, one query flag contains all the stack sizes, like Readable Label Depth and the MLDs, and one flag carries for all the opcodes in stack or post stack. The response is rather boring. It's just a list of sub TLVs, basically. So for the sub TLVs, the first one is for the RLD and MLD NAS sub TLV. So it contains all the maximum size stack sizes for network actions. For the MLD NAS, we have three values here, one per scope, Select HBH, and ingress to egress. From the In-Stack solution draft, the maximum possible NAS size per scope, including the bSPL and the Indicator LSE, is 17. So the valid range for those values is from two to 17, and the value of zero means the scope is unsupported. I already got feedback from Greg, so thanks, by the way, on the mailing list yesterday that this could be more efficient. I agree. I I also thought about this previously, so we could shrink those fields here a bit in the next version. The next sub TLV is for signaling in stack opcodes. So in MNA, we have seven bits of opcodes, so 128. For signaling or discovering their capabilities, we enumerate those opcodes and create a bitmap. So that means bit number n in this bitmap corresponds to opcode value number n, and if it's set to zero, the opcode is not supported. If it's set to one, the opcode is supported. Same principle applies to post stack capabilities. We have a sub-TLV for all the stack sizes. Here, we also have a one byte post stack data flag integrated. For now, there's just one single bit that indicates if we can do post stack at all or not. The other ones are reserved. And then we have two bytes, one byte each for the size of the post stack header itself and for the Readable Label Depth including the post stack header. Also note that this could include the offset between bottom of stack and post stack header size, so it's not just RLD plus post stack header size. For the supported post stack opcode sub TLV, it's exactly the same principle as for in stack opcodes. It's a bitmap, just a different subtype for the TLV. Okay. Security considerations, of course, also apply from the M and A RFCs and from the LSP ping RFC, and it also introduces a new attack vector. For example, attackers could exploit this capability discovery and attack nodes with limited MNA support by hijacking the connection and responding with larger stack sizes than the node actually supports. This then leads to the ingress node building stacks that are too large for a node, which then leads to denial of service or packet loss. Similar stuff then we've seen with I p v six extension headers. There's a lot of IANA considerations, but only because it's a lot of TLV and sub TLV and flag allocations. I won't go into detail here. It's all in the draft, I guess. So that brings me to my summary. What do we want to discover? We have InstaC capabilities, including various stack sizes, RLD, MLD per scope, so multiple values, and the list of supported opcodes. Same for post stack. We need to indicate if we can do post stack at all. We have various stack sizes here as well, which we need to discover, and a list of supported post stack network opt option opcodes action opcodes. How and when do we want to discover? We want to use LSP ping to discover after path Selection via IGP is done with sub TLVs in the LSP ping payload. And one final note here, I think that we definitely need that MNA capabilities discovery if we want to use MNA because just using the RLD from the IGP is, in my opinion, not enough because there's a lot of or there are many more constraints that we need to consider when building such stacks. So I think it's a pretty central draft for m and a, so please review, give feedback, or I'd be happy if some people also want to join as co authors on this draft. Yeah. So thanks for your time. I see we have two questions.

[00:28:02] **Zafar Ali**: Zafar Ali, Cisco Systems. So I have the same comment as what IGBT or LSR give you. M and a, o and m, or ping is not the right tool for what you're trying to do. There are many issues with it. One of them is just the scale. Two is you still need reachability to that node. You still need to be able to talk to that node. And three is that you still if there's a change in capability, you you would not get notified. So people have tried using an O and M for capability in past as well, and all of those proposals didn't go anywhere for these reasons. So I I would need to reconsider this. This this is not right place. O and M is not right tool for this.

[00:29:01] **Pavan Beeram**: Greg?

[00:29:03] **Greg Mirsky**: Yes. Thank you. Thank you for your consideration of my comments. And I think that I will follow on the farce note is my question is that how they're using LSPPing is, more advantageous than comparing to, using the management claim. So why not to use the Yang model and, let the nodes advertise their m and a capabilities?

[00:29:41] **Fabian Sowa**: Yes. I've also considered using a Yang model, and I think this could also be a valid approach. But it's orthogonal to this approach because the LSPPing one, it basically exercises the actual data plane path the packets take, and Yang models would be some out of band management. I'm not saying that LSP ping is the only way to go, but I think that actually both ones could coexist for this.

[00:30:07] **Greg Mirsky**: But as we discussed in our discussion, as we've agreed, I think that we agreed, that using LSVP has a problem in ACMP environment. So where the information you collect from OEM is not necessarily the same as information that or treatment that experienced by their data flow.

[00:30:46] **Fabian Sowa**: Yes. Yeah. I think the ECMP question is definitely something we need to discuss more about. I've seen that the the LSP ping RC has a lot of discussion for bet for that since it suffers from the same constraints. But, yeah, I think we need to look that up better for the next version than for eCMP.

[00:31:08] **Greg Mirsky**: Yes. The the the major problem with eCMP is that, the load balancing CMP environment, has been deemed, as implementation. So there are many different techniques to do the load balancing in c and p environment. So, thus, the information that you collect might not necessarily be applicable to the data flow. And that's why I have my reservations, for the use of normative language in the draft.

[00:31:50] **Fabian Sowa**: Yeah. I see. Thanks you for the comment.

[00:31:54] **Greg Mirsky**: Okay. Thank you.

[00:32:14] **Shuyang Yah**: Hello, everyone. Hi, I'm on behalf of the co authors to present that has dropped.

[00:32:24] **Shuyang Yah**: This

[00:32:33] **Shuyang Yah**: draft is about NPS network action for deterministic networking. This draft is mainly to address the problem. Dinette requires bound data latency, low loss, and the order delivery. But now there's no solution to define, you know, to adding and to search latency specific information to the PW encapsulated and that package. This draft specifies formats and the mechanisms for using m p s m a to support the net services, including bounded latency, low loss, and the ordering functionality. This draft now is a working group document. And recently, we have posted the re reversion zero one. And in this updated version, in stack reference has been changed from the this draft to RFC, and we also make some synchronizations with the latest postdoc reference draft. And the terminology and abbreviations are updated. Especially, the reference for in stacking coding draft it's changed from the draft m and a header to IFC nine nine nine four, and the the figure description updated correspondingly. At about the post docking coding, there are some updates. First one is, you know, mainly to make some alignment with the latest PST stack header draft. And for the sequence number, we also made some clarifications mainly on because sequence number have zero base, 60 base, and 28 base. And so we added some clarifications on the length of zero base. And about latency format, it also some information, you know, and some examples such as latency class and time stamps. This draft actually provides two options. First one is about to use stack m and a. And to support that net services, three NASes introduced in this draft. The first one is to indicate latency information. And the second one is about flow ID, which is used to identify flow, you know, identification. Yeah. And the nursery is used for sequence number and mainly used to support PREOF functionalities. The figure shows an example for In-stack m and a coding for DetNet service support. And as we all know, DetNet services can support a single flow and aggregate flows. And aggregate flow actually has the same DetNet parameters with a single flow. So they they are designed as the same op opcode. The opcode t b a one is used for the latency information carry and in the draft way sets the IHS as Select mode. And for specific opcode, such as flow ID, which may be used to, you know, an ingress to a grass or hop by hop. And for the sequence number of code, which is mainly used to ingress to egress. And, yeah, to be three used for the flow ID and to be two used for the sequence number identification. And the second option is to use postdoc m m a coding. We use PSD header draft as reference. The mainly updates to this part is that the PFN field replaced the first label and the reserve field replaced the version at the PSH lens replace PSH lens and about the m and a post hoc header equal to replace the original one. Please say the figure. It also shows the postdoc m and a coding. And we use the p flag. When p flag is set to one, it indicates the DetNet DetNet parameters are carried in PST in postdoc. But, actually, we use the same opcode to for in stack and the postdoc. And our add on is requested to allocate three specific you know, the three NASes to that net specific use. About next step of this draft, we would like to make continue alignment with the postdoc m and a hard draft. And about the latency information format design, we will make you know, follows the latest progress of that networking group, and your feedback are welcome. Thank you.

[00:39:30] **Adrian Farrel**: Thank you for that presentation. Any questions at all? Okay. Wonderful. Thank you.

[00:40:00] **Shuyang Yah**: Hello, everyone. Can you hear me?

[00:40:03] **Adrian Farrel**: Yeah. You're good. Just shout when you want to. Oh, you've got the control of the slides. Good. Well done.

[00:40:11] **Shuyang Yah**: Okay. Okay. Thank you. And this is Lee Ann and come from China Mobile. I'm going to talk about the update of our draft. It's related to the OEM for NRP and MPLs networks. And to recap, the motivation of this draft is to extend the existing MPS OEM mechanisms to support the NRP resource revolving and fault detection. And I want to mention that is that our basic approach follows the eighty-two twenty-nine, and we keep the exact existing logic that ON packet are processed in the control plane. And we truly appreciate the valuable feedbacks and based on the comments that we have made, some updates to this draft. And this slide is a quick summary of the main history. The initial version defined the basic requirement and framework for an NRP OAM within the MKLSP and the trace route. And the second presentation, we define error code and clarify the the processing behavior following the r c eighty twenty twenty nine. And, also, this version, we update the security and admin sections. After our last presentation, we received the feedbacks about the error code. So we have made further in this version. And here, I'd like to thank Eric, and Jari for your thoughtful discussions. And I will explain this in more detail on the next slide. In the previous version, we proposed two error codes. And the first one is the an RP resource available. Originally, we intended to use this error code to reflect the forwarding resources status. But after discussion, we found that the response status is the forwarding plane's data. So it cannot be verified at the control plane. So at this version, we removed this error code. And the second error code, another unknown and the not supported. We previously, we want to indicate Maybe we don't know this at all. But there are two separate meanings. The first one, unknown, is intended to indicate that the node does not recognize the the input. The specific scenarios that the feature is not at this node. So based on this, we found that if the node doesn't recognize the NRP as of, it cannot report the NRP error either. So I think we we think that it also should be removed. And the last one, the node support, it's for the configured scenario. So we think that this is checkable for the ping and the trace case route function. We keep to keep it at this version. And also, as suggested, we chose the misprovisioned this was to capture this network precisely. That's all for the updates. So thank you for the time and attention. We welcome all the command that this version, and we will also continue to resend the draft based your based on your feedback. The last thing that if the WP feels this draft is ready, we are also ready to request the adoption. Thank you.

[00:45:50] **Greg Mirsky**: Greg? Thank you. So if I understand correctly, idea of the proposal is that it's based on assumption that if NRP is not properly configured in a data plane, then OEM packet will be punted to control plane. Is that correct?

[00:46:21] **Shuyang Yah**: Yes. I think so. It's follows the the current mechanism of the OM package processing.

[00:46:34] **Greg Mirsky**: But if NRP is not properly encoded in data plane for the data packet, then the packet probably will be dropped. So why you assume that treatment of OEM packet will in a data plane will be different from the data packet?

[00:47:02] **Shuyang Yah**: Yes. I think it is. If the data cannot be transformed in the data plane correctly, it will be discussed. But I I think some scenarios for the OEM, we also want some packets to be punt to the control plane. For example, the root alert or the TTL expiration. So maybe the packet But

[00:47:40] **Greg Mirsky**: it seems that your proposal is based on assumption that data plane will differentiate between data packet and OEM packets.

[00:47:53] **Shuyang Yah**: Oh, no. The assumption is that the data plane will not differentiate the data packet and the ON packet.

[00:48:05] **Greg Mirsky**: Because if

[00:48:08] **Shuyang Yah**: But if along the same, know, forwarding path.

[00:48:15] **Greg Mirsky**: So if NRP is properly if NRP is encoded in a data path in a data plane, then Yeah. If there is no NRP Selector properly encoded in a data plane, then the packet will be dropped. Would you agree?

[00:48:44] **Shuyang Yah**: Yes. But I'm not very sure this will be processed before or after the router punted the bound the packet to to the control plane. I I think for the the current, obviously, it's it's first when the TTL expiration, the packet will be first send to the control plane.

[00:49:19] **Greg Mirsky**: But I don't find there any document that discussing their escape or exception mechanism other than normal processing of the folding because there is no check. So might be you'll need to look at defining a new forwarding equivalence class for NRP so that, there you can use the detail as exception mechanism and then use a new FEC to verify if a particular NRP is configured on a note.

[00:50:16] **Shuyang Yah**: Okay. Thank you for your comments. And what I want to say that now, I think there is no difference with the current mechanism. But if I have some misunderstanding, maybe we can discuss on the mailing list to further, and I can we can also Okay. Improve our drug. Okay. Thank you.

[00:50:43] **Greg Mirsky**: Thank you.

[00:50:46] **Zafar Ali**: I'll make it quick. Zafar from Cisco. So my comment is that people fail to realize that RPA is very much parallel to DSCP, EXP. We have been operating network for three, three, years with with that, and you've changed the field and you figure out where if if this if this e x p is broken somewhere or the forwarding is broken somewhere because of this e x p. So I think it's it's it's overly getting complicated. I don't know why you cannot just do it. Prepare a packet with a specific NRP ID and and use your your typical O and M mechanism to see where it breaks, where it's working, and that should suffice. So

[00:51:39] **Shuyang Yah**: We just reuse the OEM mechanism to de detector the NRP network, I think. So we didn't try to introduce new things or new mechanism. Hopefully, it helps.

[00:52:01] **Zafar Ali**: Thank you. I I couldn't understand your response, but it's

[00:52:03] **Adrian Farrel**: Yeah. So so thanks. I think there is some communication issues there, so maybe mailing list. Thank you. Thank you both. Move on.

[00:52:13] **Shuyang Yah**: Thank you very much. We can talk in the mailing list.

[00:52:20] **Joel Halpern**: Joel. Thank you. I'm Joel Halpern with HPE. Greg Mursky and I co authored this draft on using MNA to carry explicit congestion notification. ECN is necessary is useful. Necessary, different people argue. Useful for a lot of cases. One that's gotten a lot of attention in various networks is it's used for L4S which produces interesting reductions in improvements in user experience by reducing latency. Very useful. There is an MPLS mechanism defined for carrying ECN in RFC 5129. If that meets your needs, go ahead. We're not asking to deprecate that but it's got a problem. You can't use that with the MPLS quality of service marking because it takes away the code points. So you're sort of stuck. But MNA gives us the ability to do something better. So we've tried to spell out how could we do something better and we've got two encodings. This is dead simple, we're just representing the already defined ECN encodings in MNA in stack or post stack so as not to get into an argument about in stack versus post stack, we're defining it for both, use it the way you want to use it. We're not going to argue about that part. It's not worth it. So this is the encoding you need for in stack data. An opcode, ECN_ISD, and then down in the bottom of the ECN of the data, the two ECN bits defined according to RFC 6040. There's no interaction with any other code points, you just do this, it behaves just like a hop by hop data which does imply if you pop it off, you have to go check the next one because you got to propagate the ECN. That's what ECN requires. So we've got a post stack encoding. It looks remarkably similar. Guess what? It's as close as we could get to exactly the same. We're not trying to get anything different. The whole point here is merely how do you carry the two bit ECN marking without consuming the MPLS class of service when you have MNA available. It's not complicated. It's useful for some cases. It's not useful in other cases. And so we have one slide here on the operation. Node a gets an IP packet with ECN enabled. If ECN is not enabled, just don't put this opcode into the MNA stack. You don't need any extra indication that it's not enabled. You won't do anything because you see no opcode. If it is enabled, fill in the the MNA opcode, fill in the ECN bits mirroring what's in the IP packet according to the rules for tunnel encapsulation. Already with there's an already an RFC on Haoyu carry ECN when you're tunneling. Transit nodes to detect congestion mark the ECN at the egress when you're copying it out, you have to copy that back from the mna into the underlying packet just the way the existing tunnel draft, tunnel RFCs tell you you have to do. We're following the rules that have been laid down. We welcome comments and questions. If people don't see a problem, we'll probably go ask for adoption on the list in the near future. Adrian, I think you're the first one.

[00:56:18] **Adrian Farrel**: Hey, Joel. This is me as an individual, but too lazy to get up and go to the mic. Can you just, for everybody, clarify in the context of the the new fan working group that the congestion notification you're talking about here models or congestion notification that we've been used to, which is to say a noticing node notifying an edge point.

[00:56:51] **Joel Halpern**: This is a node which sees congestion marks the packet so that the node that finally receives the packet can detect that there was congestion along the path and according to the existing ECN RFCs may notify the ingress and respond. We're not trying to push anything back up in the network or change it. This is bog standard ECN as already exists. We're just trying to apply it to M and A when it was because we didn't think the existing 5129 was sufficient. Xu Yan?

[00:57:38] **Shuyang Yah**: Thank you, presentation.

[00:57:39] **Joel Halpern**: Speak into the mic more. Thank you.

[00:57:42] **Shuyang Yah**: Thank you. Actually, I think I've say five one twenty nine only define, you know, how to maintain the ESP values to use in values. So, actually, a cease in definition, it's domain specific. You can understand it. You know, there is no standardization for for ECN, you know, how to encapsulate. So for this draft, I think it makes some supplements at the ECN format in mpl's.net that net network. Sorry. So I think this work is very necessary. Yeah. It's valuable to support Ethan under the deployment of L4S. My question is about I, actually, I re reviewed your draft, and I noticed that you design two different opcodes for EC and carry, for EC and support. One is for ISD, and the other for PSD. So my question, why to use different opcodes?

[00:59:05] **Joel Halpern**: We simply didn't want to mandate at this stage that it was the same opcode. It can happily turn out to be the same opcode. And I believe the way the RRO is structured, that would be a sensible thing to do. We just didn't want to hard code into the draft at this point that it had to be the same opcode. But we're perfectly happy if it turns out to be just one opcode value used both in ISD and PST. Don't need it to distinguish. And thank you for taking the time to read carefully in your support.

[00:59:41] **Adrian Farrel**: Greg?

[00:59:45] **Greg Mirsky**: Thank you. Shuyang, thank you for your comment, and thank you, Joe. As we receive the feedback from early IANA review so that, the RRO for, opcodes have been updated and will reflect it in our next version, to make sure that it's one opcode that applicable to both ISD and PSD options of m and a.

[01:00:16] **Joel Halpern**: You're right, Greg. I'd forgotten that the the IANA told us, oh, we restructured the RRO so this is the network one opcode is the network way to do it.

[01:00:29] **Adrian Farrel**: Can I quickly ask the room to put their hands up if they've read this draft? Okay. That's a few, but not very many. So I think we could use more eyes on this, please.

[01:00:44] **Joel Halpern**: Please read it. Comment. Love to get feedback.

[01:00:49] **Adrian Farrel**: Thank you, Joe.

[01:00:50] **Joel Halpern**: Thank you.

[01:01:03] **Adrian Farrel**: I think it's Rakesh. Yes.

[01:01:18] **Rakesh Gandhi**: Good morning, everyone. My name is Rakesh Gandhi from Cisco Systems. I'm presenting this draft, MPLS IOAM, on behalf of my coauthors. So agenda is look at the requirements and scope of the draft, look at the various MPLS network actions in stack and post stack and next steps. So requirements is basically to carry the IOAM option types in MPLS, both various option types as well as the decks option type defined in RFC nine one nine seven as well as in nine three two six. And we leverage both in stack and post stack network accents. So what's realized? Various IOAM options types, including pre allocated end to end proof of transit as well as direct export. What's not realized is the incremental trace option that's not supported. So there's a typo in the slide. So the first one, IOAM and IOAMDAX. That's that's two methods. So first one, IOAM and the DAX in PSD. So it has a in stack m and a, and there is an op code for it and an offset where the data is because data is in PSD. And the regular scope and the u flag and whatnot applies the same way as it would be for any network action. And here is the IOAM data field that contains the the the namespace ID, as well as option type, as well as various fields related to that option type, which is copied as is from the RFCs nine one nine seven or nine three two six. Because remember, this is just an m MPLS encapsulations for those option types. So there is also a DEX solution for ISD. In this case, PSD is support is not needed. The the whole DEX, including a namespace ID, is carried in ISD, except that the encoding is reformatted to allow for the stack beat and the BSPL alias a bit. But other than that, there is flow ID as well as the sequence number and the black flag fields defined the same way as in the decks RFC. So various scopes so some option types are applicable only to I-to-E scope. For example, decks as well as E-to-E and whatnot. For hop by hop scope, there's a pre allocated proof for transit to DAX. The Select scope is is very similar to hop by hop, but it works the same way as it would be for any m and a action. And again, incremental is not supported. So there's request for a couple of op codes. So TBA one is used the same op code is used for InstaC and postdoc. And the second one, TBA two, is just for the decks in IST. So welcome your review comments and suggestions. We believe the document is ready for a PLS working class call. We are presenting this in IPPM also on Thursday to get their feedback. And that's all I had. Any comments?

[01:05:13] **Adrian Farrel**: Yeah. I appreciate you taking this to IPPM as well. It's it's obviously when we get to working group last call, we will do that jointly with them. I would like, as usual, before we hit working group last call to make sure that the working group has read and commented, but I can't make you do that. It'd be nice, wouldn't it? Yeah. You're not allowed to leave the room until you've reviewed Rakesh's draft.

[01:05:49] **Greg Mirsky**: Thank you,

[01:05:55] **Adrian Farrel**: No comments? Okay.

[01:05:57] **Zafar Ali**: Yeah.

[01:05:57] **Rakesh Gandhi**: Thank you.

[01:05:59] **Tarek Saad**: Do you think you are Donald Trump?

[01:06:04] **Adrian Farrel**: Donald Trump, excuse me. Alright. Pavan, I think the whole of the rest of the meeting is yours.

[01:06:21] **Tarek Saad**: Thank you. So this is

[01:06:24] **Pavan Beeram**: a new draft. This talks about realizing RFCPT tunnels on a shared MPLS forwarding plane using segment routing adjacency sets. I'm Pavan Beeram. I'm presenting this on behalf of my coauthors, Kireeti Kompella and Andy Smith. This draft builds on top of RFC eight five seven seven. RFC eight five seven seven was published back in 2019. We have had a shipping implementation for this for more than six years now. For those of you who may not recall, RFC eight five seven seven is this document that introduced the notion of TE-link labels. T link labels are pulling, popping forward labels that would enable you to have a shared MPLS forwarding pane over which RSVP tunnels are realized. Segment routing adjacency sets provide the exact same forwarding semantics. So if you have a network that's running both segment routing and RSVP pop and forward functionality, you end up having two separate label systems trying to do the same things on same links. So what this draft is trying to advocate is to simply use segment routing adjacency sets to realize a shared MPLS forwarding plane or which RSVP tunnels are brought up. And that would eliminate duplication that would come into play when you have two separate label systems. The obvious insight here is that both the TE-link labels as defined in r c eight five seven seven and the per link segment routing adjacency sets are undistinguishable in the forwarding plane. So if you replace TLINK labels with SR adjacency sets, the label stack that you end up formulating and imposing at the ingress would look exactly the same. So how does this work? There's no there are no changes to how our adjacency sits or allocated and maintained. The rest of the procedures are very similar to what RFC eight five seven seven defines. You have the head end of the TE tunnel compute I mean, you leveraging either an on box compute engine or an off box compute engine to compute the end to end path. It would take the specified constraints and optimization objectives, compute the end to end path. It can obviously determine predetermine the stack of labels that need to be imposed. And once the computation is done, the signaling plane will take over. RSVP would use a path message to signal to initiate the signaling sequence. There is a bit that we have defined that would mandate the use of segment routing adjacency sets, and each transit node would verify if that adjacency set is available and then record its usage in the RRO that makes its way back to the ingress. And, obviously, there are no there's no labeled route programming or allocation of labels that comes into play here. So once the signaling sequence is complete, the head end would construct a stack of labels from the recorded labels received in the RRO and for program the forwarding path for that particular TE tunnel, exactly the same as what r s eight five seven seven defines. Why are we doing this? The motivation is the same as what is defined in r s eight five seven seven. The intent here is to bring in all the features that r s e p t offers today, distributed bandwidth management, auto bandwidth, admission control, propriety preemption. All of those things will just work for free in this paradigm. Given that you are adding a signaling plan to a shared forwarding plan, you can also leverage features like automatic delegation of label stacking position. That's a feature that's defined in RFC eight five seven seven in elaborate detail. That works in this paradigm as well when you start using adjacency sets. The protocol extensions are a minimum by or fairly minimal by design. There's a bit that we defined that will mandate the use of adjacency sets. There is a flag in that RRO that will help distinguish the type of label that's getting recorded, and we have a couple of error codes to cover for mismatch scenarios. Everything else, all the other procedures are exactly the same as what you would expect in a typical RCPT network. The takeaways, I mean, we are trying to unify the forwarding plane. If you wanna do pop and forward for a TE path, irrespective of whether you use regular SR policies or a bandwidth engineered RSVP tunnel, You use the same forwarding plane. We are trying to preserve a distributed bandwidth toolkit, and we are trying to do all of that with minimal protocol changes. And at this point in time, we would like to request the working group to review the document and provide us with feedback on the viability of this. That's all I have.

[01:11:45] **Alexander Vainshtein**: Sasha Sasha Weinstein, do I understand did I understand you correctly that in this case, the head and node would actually push a stack of adjustments as it is on on the back? Okay. So I have thank you for clarification. I have probably missed that. But the question is, can protected suggestions, I said, this be used in the scheme? And if yes, what does it mean for facility protection?

[01:12:22] **Pavan Beeram**: So r c eight five seven seven talks abouTE-link production using existing techniques. The same thing would work here. You can have a separate SID, a production SID at every PLR act as so act as a SID that you would use when you start when production kicks in. No changes there.

[01:12:43] **Alexander Vainshtein**: What what I was thank you again. And I think that Somehow, I think you should avoid the case when on one k on one hand, you use protected address and say say this, and the other hand, you use facility FRR, RCPC FRR, and this somehow has to be indicated by the head and what to use, what what is and what isn't, what should and what shouldn't be used. Because if so, it Because if if someHaoyu use both, the results would most probably be unpredictable. No. The because we are

[01:13:28] **Pavan Beeram**: using the existing fast shared object and the flags will tell you that you have to use existing forty ninety procedures, you will use facility backup. There is no way to ask for, say, use something that is not forty ninety. But we use the notion of a production set because we want to make a distinction between unproductive sets and production sets at the PLR. Okay. There is a section that talks about that in detail.

[01:13:57] **Alexander Vainshtein**: Okay. Thank you.

[01:14:02] **Zafar Ali**: Zafar Ali Cisco Systems. So I'm I think we're going back to where SR against the old thing that SR was was was invented for and designed for and and and people like it, is the removal of the state from the network. Now IGP programs these SITs, so there is no reasons for signaling to go and reinvent and do this. RCP does it because there is nobody programming those agencies, those programming. So the main job for RCP is to signal the programming of the LSRs, at the LSRs. Here you are you're going, you're introducing states in the network that were designed for the mean stateless. IGP is there. I mean, I don't know where where we're going. This is this is completely against the SR architecture. This this is

[01:15:07] **Pavan Beeram**: I think you're going saying on record that you don't want you don't believe in distributed bandwidth management, which is fine, But this is for scenarios where you do want to use a shared for MPLS forwarding plane and SR using SR adjacency sets, but you want to leverage distributed bandwidth engineering. And right now, the only way to do that is r s v with r s v p t.

[01:15:26] **Zafar Ali**: There's there's things that are done in in in a in PC working group for all the bandwidth management. There is a auto bandwidth draft, which is either either way close to last call or it's it's been done. But the main issue is that you are for for this little thing, you're introducing a whole state. The you you are ignoring that IGP is there to program. It's it's there. You might as well just remove that and and use RSCPTE, which is fine. I mean, then then just use top up label. You don't have to do any of this. What is the game? You you can just run RSCPTE network and and do none of this. Don't don't use any of the SR cement. It's still

[01:16:12] **Pavan Beeram**: I mean

[01:16:12] **Zafar Ali**: be done.

[01:16:13] **Pavan Beeram**: Are requirements where you still want to preserve the notion of a shared forwarding plane. We we instead of using traditional swap labels, you wanna use a shared forwarding plane, and you you still wanna use distributed bandwidth engineering. And that's where this comes into play. If you are saying that you're going to rely only on centralized controllers, which is fine, this is not that particular solution. Is there a forwarding plane

[01:16:37] **Joel Halpern**: Gentlemen, we're out

[01:16:38] **Zafar Ali**: of line. Not shared between SRMPLs and MPLS.

[01:16:41] **Tarek Saad**: Gentlemen, we're out

[01:16:42] **Zafar Ali**: of time. Next question, please. RCP.

[01:16:45] **Joel Halpern**: Take it to the mailing list, please.

[01:16:49] **Pavan Beeram**: Himanshu Shah from Sienna. Clarification question on EXP bit sets. Is it done by the head end and on all the labels that I've pushed on the stack? You're asking about EXP? Yeah. The There's no orthogonal to what? Because it's popped off, right, at every hub. So Yeah. It's just the it works the way you would it would work on, say, an SR policy today. Yeah. But RSVP is little more stringent than bandwidth aware and all that stuff. So you have reserved bandwidth along with the and it is shared. Right? So it's more important to preserve those EXP bits and properly queue it at every hop. We can add some clarification text on how that works. Okay. Yeah. Cover those things.

[01:17:35] **Adrian Farrel**: Great. I I saw Lou and Kireeti pop up on the in the queue after it got locked. Please use the mailing list.

[01:17:45] **Pavan Beeram**: K. This I have thirteen minutes, I guess. Yeah. This is an update to the fast forward extension draft that was presented at the last IETF meeting. I'm presenting this on behalf of my coauthors, Abhishek Deshmukh and Tarek Saad. Quick recap. I mean, today, the ingress has limited influence on how the backup part gets computed at the PLR. You could carry some limited set of constraints like bandwidth, top limit, priorities, and affinities in the existing fast shared object, but nothing more than that. What a head end cannot do today is specify the optimization objective that needs to be used for the backup path. It cannot specify any link scope or path scope bounded metrics that the backup path computation needs to take into account. All of that is done today using local PLR policies, and that's the gap that this draft is trying to address. We are introducing a new object called the FAST-FRR extension object. It is a companion object that gets a companion to the fast existing FAST-FRR object that gets signaled in the path message. It's an extensible TLB based object with a couple of TLBs defined today. The optimization metric TLB is used to specify what optimization objective needs to be taken into account. For the backup path, you can specify things like optimize for team metric or optimize for delay and so on. The bounded metric TLE is used to specify a hard bounded metric constraints. You can say things like do not exceed ten millisecond delay on this backup path or do not avoid any link that doesn't meet a certain delay variation threshold. The procedures are backwards compatible. A PLR that does not comply with the request that's coming in can always fall back onto the local policy that's specified at the PLR. And we have procedures in play that lets the ingress node know which particular PLRs have complied with the request and which haven't. These are the changes that we made in the new version. There's a new everything is editorial in nature. We have a new coauthor. We added a section that illustrates the part message format. There is there was a missing IR subRRO for Metric TLV flags. We added that, and we also tightened some normative language for a couple of procedures. The the reason for presenting this again is to request working group adoption. I mean, it the draft addresses a well bounded problem. It provides procedures that are backwards compatible. It provides an extension that is future proof. I mean, it can be it can cater to any future use cases that come into play. We do have an implementation that is getting ready for to be shipped. So we would really like to get early code points for what for the what this draft is advocating. At this point in time, we believe the document is sufficiently big for it to be considered for working or production. We also think it's mature and detailed enough for it to be considered eligible for early code points. That's all I have.

[01:21:21] **Adrian Farrel**: So how urgent are these code points? If we were to do adoption first and take a, you know, a few weeks over that, would that cause you problems?

[01:21:30] **Pavan Beeram**: It might, but that's okay. I think If you can get get it adopted because most of these TLV registries are new, I don't expect anybody else to take them. So we we would be able to suggest some code points.

[01:21:45] **Adrian Farrel**: Yeah. Yeah. It's it's more the stability of the document document that that worries me once we you know, if we burn a code point and then something changes, it gets embarrassing.

[01:21:57] **Pavan Beeram**: Understand. So that's why we have added lots of detail, and we are hoping that there wouldn't be too much resistance.

[01:22:05] **Adrian Farrel**: Yeah. Zafar, please.

[01:22:10] **Zafar Ali**: Yeah. I have a concern with the thing is is is the draft and the whole work goes through what we call law of diminishing returns. We have things that are already, like you mentioned, policies at the PLR. And it's a very nice distributed way for PLRs to do assignments. And it's working. It's working for twenty, twenty five years. Now you're coming, no. No. No. I need to influence it from head end. Fine. You can influence from a controller too. You can influence from head end. You can influence whatever. But I I really don't see much value. I think there's more complexity than value to the field.

[01:22:50] **Pavan Beeram**: I can explain why this is kind of new. I mean, yes, you're right. We have had all these implementations running for more than two decades now, but the number of TE path profiles that are getting deployed have changed. And, also, the fluidity for these part profiles are also changing. I mean, in the past, you could you would just create one or two TE path profiles, and they would be rigid over a period of time, but that isn't the case anymore. You can always go rely on your centralized controller and do everything, but, yeah, I mean, we define protocols here.

[01:23:23] **Zafar Ali**: It's it's not about central control. It's about the local policies. You can you can have those local policies and and apply. I like it that way because then PLRs in the places has independence, more scalable, better control, local control, not external influence. This but but there this is these are some of the some of the technical aspect. I think we should consider them before moving forward with this.

[01:23:58] **Adrian Farrel**: That looks like it, I think. Okay. Anybody else?

[01:24:03] **Pavan Beeram**: Do you want me to send a formal request on list? I think I

[01:24:06] **Adrian Farrel**: can Always worth nudging the chairs, especially Tarek who's probably asleep by now.

[01:24:12] **Pavan Beeram**: He is a 0.25. I guess he would need to recuse himself for the process.

[01:24:17] **Adrian Farrel**: Doesn't stop you nudging him. Yeah. Yeah. Please, and this applies to everybody. If you don't see the chairs acting on a request quickly, then remind them.

[01:24:28] **Pavan Beeram**: I'll do it.

[01:24:28] **Shuyang Yah**: Thank you.

[01:24:30] **Adrian Farrel**: Okay. We got yeah. Why not?

[01:24:34] **Zafar Ali**: What what interrupt? What interrupt? I'm sorry? What what what interrupt you need these code points so urgently for?

[01:24:45] **Pavan Beeram**: I said I'm shipping an implementation, but, yeah, having a code point would let me do interrupt. But the urgency is because I'm shipping a product.

[01:24:53] **Zafar Ali**: Okay. No. No. No. I think the reason I asked because you had this And it was a unique one by unallocated.

[01:24:58] **Pavan Beeram**: Understand what you're trying to say. But yeah. I mean, we can always have another vendor. I mean, there are two vendors on the draft, so I'm assuming that they would be an implementation at some point.

[01:25:12] **Adrian Farrel**: Thank you. Anybody or any other issues for the working group in general? Right. Well, it looks like you're gonna get an extra five minutes in your break. Please enjoy it. And I would say see you in San Francisco, but I won't see you in San Francisco. But, you know, there will be a meeting probably. If

[01:25:41] **Joel Halpern**: anyone's there.

[01:25:53] **Adrian Farrel**: Interesting feature. Well done, sir. Thank you. Feature. If the person controlling the slides leaves the room, the slides go on.