Session Date/Time: 20 Jul 2026 12:00
[00:00:16] Satoru Matsushima: Now 2PM in Vienna. Fools so we start meeting. DMM working group in IETF 120. So welcome. This is Satoru from SoftBank. My co chair, Sri, couldn't be able to come, so I chaired this meeting. Okay. Please read Note Well. Bound you. So you have to know the professional to behave, and you have to know the IPR and awareness of IETF process. So please detail yourself. Before we start, we need notetaker and Jabber scribe. Does anyone volunteer for that? Jabber scribe as well if needed. Okay. You can find agenda from the link, but you can see the working group status update here. We have six working group document. Agenda topic today is the working status and action item since from previous meeting 119 since then. We have one IESG review document, TN-aware mobility, and we have a four slots for working group document. And we have two individual draft to be present. So let's review the IESG status. We have one discussed position from ops area AD. So what's the ops area AD claim is that the the the TN-aware mobility draft feels something like a only solution for the mobility we are surfacing. But he said that the IETf previously released the the document with the many solution for that. So he's positioned to discuss what take this document as the one of the solution technique to realize the network sizing for the mobility 33GPP mobile system. So, John, do you have any idea, opinion from this discuss?
[00:04:17] John Kaippallimalil: Actually, I haven't looked at this specifically. So the immediate thought that comes to my mind is that, you know, this mobility aware has come up even during the our working group discussions, and we resolved it a few times. So if we need to address it, I think we can we can address it to remove that confusion about the mobility aware part, and that may make it more clear for the whole group as such. If that's okay with the working group, we can proceed in that way.
[00:04:52] Satoru Matsushima: Okay.
[00:04:52] John Kaippallimalil: That was my thinking.
[00:04:58] Eric Klein: Eric Klein, I guess former AD hat on. The document is informational. Right? And we went to great pains, two and a half years worth of great pains to make 9433 informational. So I'm not sure that this discuss is really discuss worthy.
[00:05:19] Satoru Matsushima: Okay.
[00:05:21] Eric Klein: So but I guess that's feedback for the new AD. Tommy Jensen is the new AD. As long as the working group like, as long as everyone agrees with that, I'm happy to stand behind that and move this forward.
[00:05:41] Satoru Matsushima: Okay. Thank you. Okay. So take care of his discussion as much as possible. So but we may revise the draft to address. Not too much change. And he also asked the some sort of the liaison with this 33GPP slicing. So if also would like to do, I I can help. And, also, I think we can send the related document to the 33GPP if we have made a liaison.
[00:06:29] John Kaippallimalil: May I come Okay. So I I've been attending the SA2 quite a bit. I mean, with everything that's going on, it's really six g that they're working on. And slicing is really handled more than SA5. I don't know if we should send an, you know, a question to 33GPP because they're not gonna spend time on that. I'm pretty sure about that. So I think we can I don't know? My my view is that we don't need to send that link. Okay.
[00:07:05] Satoru Matsushima: That's fine. Okay. Thank you very much. Nope. So next presenter will be John from UDP tunnel extension YANG.
[00:08:03] Teppei Kamata: Okay.
[00:08:10] John Kaippallimalil: Thank you, Satoru. So this is the YANG model for attachment circuit as a service update. So so we don't have much of an update over here because this has been reviewed and it was you know, if you look at the history, this was part of the other informational draft also which looked at the slicing. And now this was separated out to be a standard track document I mean, draft. And the the other one which explained about all the details on slicing is what we just talked about a minute back, and that's that's an informational draft. So the the t n aware mobility draft refers to this structure and uses it for slicing, but this itself is not structure here, the YANG structure here, is not specific to the slicing alone. This is talking about a layer three bearer with a UDP count as a bearer. So if you can if if you see over here, you can see there's a UDP port, and the structure allows you to define upper and lower port boundaries for the UDP and also a range a range and also the port number. So that's that's what this is allowing you to do, and it can be used in the as an ACaaS structure for for the other draft that we've defined, but it's also more general. At the moment, we have the the this has been reviewed by the operations management side. The YANG structures have been generated without any errors, and that's and we have not received any other further comment for updates. So at the moment, I think it is really ready, the structure itself. The other part of the draft is the example that was requested in earlier reviews, and now it's showing a general one that a general model that shows how the structures can be used. So you can see the UDP bearer that's on both sides. So that's exactly what has been used. There's been no update. The only comment we've gotten this is a few days ago from the early review that the registration templates in the section should match RFC 9207. The updates look pretty straightforward, and you can see on what's on the right is really a couple of minor changes to change sub-registry to registry and then put registry group in each of those subsections. I've made those updates and updated I mean, uploaded the version one. So, actually, you know, I didn't I mean, so this this is referring to zero zero of the draft. Zero one of the draft has made those changes to be compliant with 9207. So I think at the moment, all the comments have been addressed, and the YANG structures are are good, I think. So if I had to summarize, really, the all the YANG aspects have been reviewed, The update has also been done now, actually. It's not a to do anymore. I think the draft has been reviewed multiple times along with the earlier document as well as, you know, when we generated the new comp compiled versions here. So thanks for all the reviews, and I think which the authors would like to go ahead with progressing this draft if possible.
[00:12:10] Satoru Matsushima: I have made some one poll for how many people read that draft, but I think draft shape is good. Okay. Any question, clarification?
[00:12:42] Tingji Ge: Yes.
[00:12:47] John Kaippallimalil: Only only that. Yes. Thanks.
[00:12:55] Satoru Matsushima: Okay. I think draft is really concise and really for a working group last call. So I may have a I mean, I may make up the poll for the the last call in the mailing list. Okay? Thank you. Thank you. I think Soon. This is the MUP architecture draft update in revision two. So I and my co-authors made the the some update in this revision. The new one is the illustration section. It has distributed home routed roaming with multiple home operator case in section seven dot five. So it's based on the two protocol level update to be to be able to the home routed roaming. So one is ST2 route update. The ST2 route can now steer packet to a destination interwork segment. Interwork segment facing to the 33GPP or the mobile service system, such like N3 interface or N9 interface. So so from ST2 route be leveraged to handle the tunnel packet and decap, but now it can be leveraged to towards the the mobile side of packet with the steering to the next interwork segment. The other one is MUP extended community. The new interwork segment type be added alongside the existing direct segment type. The term terminology in MUP architecture will be different from the well known mobile subsystem, but the direct segment means that the kind of the the DN. But in addition to that, the interwork segment be identified by extended community as well as the direct segment. And security consideration in sectioN9 is also fully written. It be closed the action item from the previous IETF meeting. Okay? So let let me explain the ST2 route update a bit. The ST2 route steer to steer the packet to a destination interwork segment. So far, the ST2 route as known as type two session transformer route only carry a direct segment extended community. That mean match the packet to route are decapsulated and look up locally in the direct segment. It mean kind of the DN. From revision two, a ST2 route can now insert carry a interwork segment extended community. It mean the matched packet to ST2 before added toward a destination interwork segment. For example, specific home operator of the N9 N9 network instead of being decapsulated locally. The second point is the route may also carry the session information of the destination tunnel endpoint. F-TEID, for example, of the 33GPP case, it's enabling endpoint translate translation. For example, the packet come from the mobile side to the N3 F-TEID, I mean, for example, the UPF address plus TEID, and then packets forwarded to the N9 network with home network UPF address and TEID in the case of the home routed roaming. I don't know how many people are aware of the 33GPP home route home routed roaming case, but if you are interested in and you if you need to know that case, please read the 33GPP documents in the reference of the this draft. So to resolve the the forwarding next op or destination, So resolution rule here, such ST two route are resolved only against ISD. ISD is interwork segment discovery route carrying the matching interwork segment community. The rule is the ST2 route attached with the interwork segment community ID, and then that ST2 route need to be resolved with the discovery route of the intervox segment, which has the same community value of the intervox segment. That's the resolution rule. So second update is MUP extended community for interlock segment type. As I mentioned before, the max MUP extended community only defined for direct segment. But from revision two, the interlock segment type be defined as a MUP extend community. That's community attached to ISD interlock segment discovery route, to identify and separate multiple interlock segment. For example, a N9 network toward home network home operator a or home operator b. Each home operator's routing or addressing policy stayed isolated even when their N9 address space overlap. A ST2 route with no interwork segment community is implicitly the default interwork segment. Preserve the previous behavior. It'll be straightforward. Okay. This ask here to be complicated, but the these two figures show that the the two home operator be connected to the one serving operator network, which has SRv6 MUP deployment? And the ref right hand side, the one of the home operator connect to serving operator as well, but the home operator PE connected to the close PE router in the serving operator, which means that the almost same location of the radio access network be deployed over the home network operator, which is a little bit interesting to the current deployment. So both case, home routed roaming Upland packet are handled directly between the MUP p, which means that no traversal of the serving operator, the UPF, for the packet of the MUP PE handled session. And interlock segment community, For example, I one for home operator a and I two for operator b, keep each home operator's routing address policy separated even with the overlapping n N9 address space. So please read this draft. You can find in much more detail, and please give feedback for that. Okay. Security consideration I made here is almost five point. One in routing control plane. So MUP architecture, adaptive routing architecture for the mobile user plane, so which require protected routing control plane to avoid the spoofing tamper, the transformer routing information, and discovery route. And if the second point is BGP case, when BGP is used, it should follow the operational and security practice, and BGP session must be restricted to authorized queue, which is obvious. And import export policy is very important to ensure MUP route propagate propagated only within the intended routing instance. And fourth point is evaluation resolution of the session transport route. When the resolving segment discovery route is resolved or it's community change, that's timing. Operator should not reassign sorry. The ST route be redidovered again, and operator should not reassign a interwork segment community value while still differ difference referencing its domain advertised. So last point is a SRv6 data plan deployment must follow the security consideration with the RFC 8754 and 8986. The summary of the and next stop next step, the this revision had distributed home routing home routed roaming with multiple home operator case with the two protocol update, and the security consideration is fully written. The next step, we also would request the working group to review the ST two route, MUP extended community update, and the section seven dot five illustration for the HR home routed roaming. And that's all. Any question or clarification?
[00:26:26] Tom Hill: Hi there. Tom Hill from British Telecom. I'm sorry to have to tell you, but we probably need to reopen the item on security considerations. Mhmm. The draft SRv6 security considerations draft is nearing completion. It's nearly ready. But the reason that that was one of the reasons that that was written was because RFC 8754 and 8986 didn't go into nearly enough detail in regards to security considerations for operating SRv6. So it would certainly be important, I think, to make reference to that draft as soon as possible. The the other part I would be very careful about is where we have the the phrase inter domain because there's some ambiguity to that. Particularly, we talk about this in the as the trusted domain that's that's referenced in the the original SR segment routing draft. That's referenced heavily within the security considerations draft as well. And there's been a very important point recently raised that we shouldn't be defining what inter domain SRv6 is at any point. So we have to be very careful when we when we speak about this because, technically, if you follow the letter of the RFCs, it's not permitted.
[00:27:41] Satoru Matsushima: That's it. Okay. Thank you very much. We have to take look on the new security draft button.
[00:27:49] Tom Hill: I've just read it. Okay. Thanks. So so I think as of as of how it is exactly right now on the data tracker, it needs some updates.
[00:27:57] Satoru Matsushima: Okay. So one note here is the this roaming case is not for the inter domain service case. It's the kind of just legacy roaming interconnection between the serving and home operator.
[00:28:12] Tom Hill: I thought you were thinking more of roaming, maybe, but I I don't know. Either way, we have to be a little bit more verbose when we talk about interdomain. What are the use cases? What is that being used for? How far apart are those organizations?
[00:28:29] Satoru Matsushima: Interdomain for SRv6 or interdomain for mobile operator? S r v six.
[00:28:36] Teppei Kamata: Okay.
[00:28:36] Satoru Matsushima: Yeah. It's not really focused on the this last. Mhmm.
[00:28:44] Tom Hill: Okay.
[00:28:54] Satoru Matsushima: Any question? The update really complicated for readers, but please read that. How many people read the draft of update? Great. Thank you. So if you take the role of the reviews, I really appreciate it. Okay. Thank you.
[00:29:53] Marco Liebsch: Oh. So far, I'm online.
[00:29:56] Satoru Matsushima: Okay. Oh, really?
[00:29:57] Marco Liebsch: Yeah. Yeah. Yeah.
[00:29:59] Satoru Matsushima: Okay. Can you handle this? Right? Can you
[00:30:02] Marco Liebsch: So I need to request screen share. Right? How can I progress?
[00:30:15] Satoru Matsushima: I think you now are to
[00:30:18] Marco Liebsch: Now I can. Yes. Great.
[00:30:19] Satoru Matsushima: Okay. Alright.
[00:30:23] Marco Liebsch: So so yeah. That's me. So, well, online is very different from being at IETf to discuss and present, but it will work like that. So we wanna provide you with a quick overview and update on the mobile traffic steering draft. It's currently available in its second revision and progress here. Quickly about the the background. Again, it's meant to extend and complement the control of mobile traffic, which applies between a mobile communication system and a correspondent note, which may be a service in a data network or another UE, another mobile device. In between, there is a transport network. So just the latest steps. So version four of the individual draft has been adopted as working group draft, which we published in December 25. Currently, we have the second revision. Quickly about what came in since its adoption. So the version zero of the adopted working group draft includes John's review comments, and we address all of them, hopefully. And version one actually introduced also comments and feedback from Carlos' intensive review. And the current version two has a number of editor and it's also text editor security consideration section. And in particular, the information model has been tweaked a little bit. So it's a basic model, which is extensible. From the structure point of view, we think it's pretty concise. So we address actually in line with how the 3GPP develops reference architecture, which is pretty, let's say, generic and not binding to three 3GPP, but pretty much applies to it or can be applied to it. Then in particular, we look at use cases, their operation. We discussed a couple of them here. More of them exist, of co-authors. But in particular, we want to address the dynamics in an end to end path, either decided by a mobile communication system or by the transport network in between a mobile node and its corresponding node or service. Also, user mobile user device or user plane anchor communications address, and in particular, also node abnormality, which applies to a couple of use cases like nodes that enter foreseen or scheduled or unforeseen dormancy or energy saving mode, or they may be affirmative because of their nature to move, right, like satellites. So that's what we discuss and address here. So a couple of use cases. To tackle this, we recommend and propose a framework and also different deployment options based on two key functional elements, either based on the dedicated controller and control plane, another one more in a decentralized fashion. And then we are very clear on which is in scope of the definitions that we do in this draft in terms of the control interfaces and which is out of scope but flexible or different demands are possible here. Then we discuss based on these two modes, based on a dedicated control plane or decentralized control plane, operational aspects and modes. So three modes are being discussed here, and that gives a lot of flexibility in how that draft can be further tailored and then also developed and used. There are not much or actually no IANA considerations here, but we added text on security considerations section. And currently, the information model is in the appendix. It's basic. But from last time and when we presented in Hong Kong, we proposed that we further progress this based on an entity rational diagram, which I briefly show. But this draft has a MUPping to a table representation, which is more suitable for SQ based IETF drafts. And we also still have an appendix b, an exemplary application of this draft to 33GPP's architecture. That's something which we would like to address quickly and maybe get your feedback until the next revision how to handle this. Quick reference architecture. As you see on the left side, there is mobile communications system. We do not interfere at all with that one, but mainly address the path in between the system's user plane anchor, then the data plane network in between. And then on the right hand side, you see the data network with the services in there. The main interfaces, as you see here, for the two deployment options with controllers or decentralized is the interface between what we do know the c one and c two. So this is the interface for the control plane and mobile traffic steering. Of co-authors, the impact of that steering then will be enforced on the user and data plane, which you see in between interfaces t one and t two. So now the current status and plan so we are interested in progressing this quickly, getting all your feedback, and closing this work soon, but apply all the changes and revisions that are needed, of co-authors. So we consider the current version mature, and some particular checks and feedback we would like to get from the working group is about the following four bullets. So I think it was from Carlos. He suggested to also add a picture on the note of familiarity use case. And since we talk about non-terrestrial notes here, we added a picture here, but believe it may be too confusing, but maybe not too confusing for those people who are familiar with non-terrestrial nodes. Right? So it talks about having user plane anchor of the mobile communication system and data plane nodes applied in space in a more agile topology because these nodes actually move. So here, we would like to get feedback if you consider that as appropriate or not. Otherwise, we can break it down to a more simplistic use case maybe based on energy saving mode or something like that. Also, the operational aspect section tries to describe the use of this interface that we introduced here based on the different use cases and relocation scenarios. If you see the need for more cases and description here, we're happy to implement this. The information model, and we have a slide on that later on, is something that we represent in the table format now, and we hope it's clear, but it's extensible. Right? So a few words on that in a minute and then on appendix b. So the whole draft is actually using similar architectural notes as three 3GPP considers in the current architecture and its evolution towards six g. Nevertheless, there is work in 33GPP going on for architecture study and discussion for six g systems. And this report, which is 23.801, actually references this DMM working group draft. So there is a good visibility of this work, and we just wanna see and discuss with the working group if you believe it makes sense to be a bit more specific in the appendix b, how the draft may apply to future 33GPP systems and whatnot. So these are a couple of things that we may want to get feedback from you in the session or even offline. Nevertheless, most comments that you may have, we would like to have reflected in the further revision in the next weeks and months. So that has been presented at last IETF, which is we started with an ERD to actually come up with relation diagram for this work that applies to the API that we specified, the MTS. And we have actually four elements that relate to each other based mainly on the traffic description, then the UPA note that traffic currently uses, then a path in between the UPA and the data network, and the path is made out of chain of VPN notes. So that's the basic principle, each of them having an unobitious identifier and then attributes which describe actually particularities of the elements. And this is what you currently find in the draft, which has a table representation of these elements. Basically, traffic, the path, the UPA, and the chain of VPNs. So each has particularities. The traffic has mandatory but also optional parameters because it has a draft descriptor. We give space for session descriptors, which is more something the mobile communication system has. So this is not a data model, but an information model. So if we have a video session description from 33GPP that may be reflected here, and it's also being used and leveraged by current DMM work. Like, have in mind the MUP controller somehow makes use of these sessions and MUPs it to routing information. So this is something we give space in the information model here. We have a data network descriptor and then basically reference the UPA identifier, which gives the currently used EPA and the path behind. Then also transaction state. So in case and we address in particular dynamic scenarios where we have changes in the end to end path. So we also have elements about the MTS transaction state and the transaction context. So state may be stable or in transit, and context gives more information behind why the state is currently in transit. So for example, the mobile communication system initiates a path change or a UPA change or even the transport network through the MTS controller initiates a change of the path and the associated UPA. So these scenarios are described in the core part and reflected here in this information model. The same for the UPA and the actual path element, which comprises a link to a chain of DPNs. So one open thing we would like to address and discuss, and that was a good comment that we discussed with Luis, actually, during last, IETF. And today, I was also in the, time variant routing session. So the comment from him was that we may take this work into account here. I'm just wondering how we can do that. And so TVR actually comprises information that's being exposed either inbound or out of bound that gives hints about a change in in the route. Right? So that's exactly what we could leverage here. So currently, as you see on the very right side in the DPN element, we have something like DPN supplementary information URI. So this is a pointer to any database which can give you more information about, hopefully, proactive change in of of a path. Right? So if a node disappears or moves, we may get early information about this. So this may be a link to the out of band mechanism to retrieve TVR information and then learn more about availability or unavailability of a note. Other mechanisms are possible. We just want to complement work of other groups here and not reinvent them. Right? So listing all these attributes that TVR specifies doesn't make sense at all. But having a good linkage, how this information could be used, that's, I think, a way to go. And I think that's it for today. In the back of this slide deck, you'll see a bit more description on how the whole mechanisms for the free modes work. But that's mainly our update presentation for today, and maybe you have a few comments or questions based on the presentation. Thanks.
[00:44:13] Satoru Matsushima: Thank you, Marco. Any question, clarification? I mean, some one poll. How many people read that draft? Okay. So thank you, Marco. Please keep the discussion in the mail or somewhere. Are you in Vienna? No?
[00:45:02] Marco Liebsch: No. No. I'm not in Vienna.
[00:45:05] Satoru Matsushima: Okay.
[00:45:08] Marco Liebsch: Yeah. But so I will maybe connect to to a couple of folks that we talked to during the last IETF and in between, and, hopefully, we can get their feedback and input so that we have and converge on that draft quickly and then have working group last call in it. But that requires a few more reads.
[00:45:38] Teppei Kamata: Okay.
[00:45:39] Marco Liebsch: Alright. Thank you.
[00:45:40] Satoru Matsushima: So please read the draft and make feedback to the Marco and the mayor. Thank you.
[00:45:45] John Kaippallimalil: Thank you.
[00:46:29] Satoru Matsushima: I made a flip I made a flip the order. So the based on can you present to your slide for the the update of the architecture discussion draft.
[00:46:51] Teppei Kamata: Sure. Thank you, Satoru san, for sharing the text. So good good morning, good afternoon. Yeah. Hi, everyone. My name is Tepe Kamata, and I will present architecture discussion on srv6 mobile user plan draft. This is a information informational draft in the DMM working group. So and today, I will briefly explain the document positioning, summarize the update in divisioN3. Okay. This presentation provides a short update on draft, I t f, draft-ietf-dmm-srv6mob-arch-03. There is a I'm explaining the four goals on here. First, I will recap the motivation and portioning of this document. Second, I will explain the update introduced in the revision zero three. Third, I will clarify the add value of SRv6 micro-segment in the SRv6 mobile user frame. And finally, I would like to ask the working group last call on this document. K. Document positioning. The DMA MUP architecture works describes a mobile user print architecture in the SR diagnostics manner. This means a previous slide. And in contrast to this document, focusing the specifically on the SRv6 based mobile user plane. The purpose of this document is to explain why SRv6 is a strong fit for MUP. In particularly, the document highlights architecture and benefit of transforming mobile session information into routing information. It also describes how segment routing capabilities can be applied to the mobile user plan while operating machines, IP routing paradigm. The document also discusses how this approach can help addresses 5G and beyond 5G user plan use cases. So this document is to the MUP architecture work, and MUP architecture draft describes the generic architecture, while this draft explains the motivation and benefits of the realizing MUP with SRv6. K. This is a motivation recap. This slide recap some basic motivation. Basic motivation is already described in the previous, meeting also, but let me explain here. The existing mobile user plan is based on the overlay tunnel sessions towards a mobile anchor point such as, UPF in the 5G context. This model is useful for some mobility scenarios, but, it becomes challenging for emerging 5G and beyond 5G requirements. As shown in the figure, traffic is carried over the GTP-U session towards anchor point. This model is not optimal for any to any communications, edge and distributed computing, and fixed mobile convergence. It also provides limited control over the under a transport bus. The limitation, much better routing based approach for the mobile user plane. So the key idea is transform mobile session information into routing information in the convert conventional mobile user plane. Mobile session information is based on pair of endpoints. For example, GTP-U session, start point, and endpoint. In contrast, routing information is based on the destination. This difference is important for scalability. For any to any communications, a session based paradigm tends to scale as o of n, squared because it depends on endpoint pair. On the other hand, the IP routing paradigm scales as o of n because, wording is based on the destination reachability. S r v six m u p takes advantage of this routing paradigm. As shown in figure, SRv6mup converts mobile session information into routing information and operates over the SRv6 network. In addition, SRv6 has important capability to the routing paradigm. It's including the explicit past tiering, policy control, faster protection, SLA differentiation, and slice of wire forwarding, and so on. So the motivation is not only to remove the tunnel session based, restriction, but also to apply SRv6 capability directly to mobile user plane. So what changed in zero three revision? In versioN3, main update, it's a clarification of SRv6 micro-segment, NEXT-C-SID flavor, which is standardized in RFC 9800. There's no change to the core architecture discussion. The draft still explains how mobile session information can be transformed into routing information and why SRv6 is suitable for mobile user plan. So mutex is mainly explained that micro-segment reduces the encapsulation overhead by representing the segment more compactly, and, this helps reduce MTU impact. And this is important for mobile user print traffic and also, clarifies a benefit across the key use cases, network slashing, edge computing, and URLLCLC. For slashing, Micro-SID, helps keep SRv6 based policy. And for edge computing, it helps when steering the traffic to distributed edge locations, including the small packet use cases. And, also, URLLCLC, this overhead can help reduce serialization, the delay, and the details. So the main message is, 03 does not change the architecture. It simply makes the Micro-SID benefit clearly in the srv6 mobile user plane deployments. So this is overlapping benefit of in the draft zero three. So as explained, it's a b six micro-segment, improves the packet efficiency and deploying deployment by segment information in more compact way. So in the draft, we describe the benefit across the three main use cases, network slashing and edge computing and URLLC. So while this additional strengthen the motivation for SRv6mup. So it's it's why SRv6 micro-segment makes some more efficient in the mobile user plane use cases. So next step. So this revision zero three adds a micro-SID benefit for network slashing and edge computing and URLLC use cases. And the document is, this document is a informational document. So core architecture motivation is stable and unchanged. So we believe that draft is ready for working group last call, I think. That's my presentation. Thank you for hearing this. Any question or comments?
[00:56:46] John Kaippallimalil: Thank you for presenting this. I had to comment really on page five, if you don't mind.
[00:56:53] Teppei Kamata: Page five?
[00:56:56] John Kaippallimalil: Related to page five. I mean, I'm sorry for the late comment. It's just that it would be good to add how you get the n square and n, you know, because 3GPP has a session controller, and the SRv6 has a session controller. So in some sense, if you've got to go to ON, then you you may wanna add a few more details about the session controller in terms of the architecture. You know? That may help clarify because, you know, otherwise, you have to do a detailed reading to understand how you get that benefit. You know? Mhmm. That's that's I can provide a comment also online if you like. Or
[00:57:41] Teppei Kamata: Okay. Thank you very much. It's not described in this document, so we'll check the
[00:57:51] John Kaippallimalil: I think it may be there, but, you know, you have to read through it to figure out the I mean, so if you're just casually reading it, you won't get the that date. That's all.
[00:58:03] Teppei Kamata: Okay. Okay. Thank you for your comment.
[00:58:11] Satoru Matsushima: Thank you, I made one poll. How many people need the draft? Go ahead.
[00:58:57] Tingji Ge: The question is also related to the page five and follow John Key on that the any to any communication. Are you trying to solve that issue with this architecture? For that since, I I tried to figure out how your proposal or changes or improvement is going to address that any-to-any communication.
[00:59:26] Teppei Kamata: Hello? Sorry. Question is yeah. My proposal one of the my proposal motivation is simply provides any training communications. It's it's a way to provide any training communications with SRv6 m u p. Of co-authors, we have the another option also, but, SRv6 mobile user plan is, one of the simpler way to provide this capability.
[01:00:10] Satoru Matsushima: Do you do you describe the end to end communication in the draft?
[01:00:19] Teppei Kamata: Yeah. I I think so. What if I I think it's described in the document, but if not your point is it's not described in the draft.
[01:00:37] Tingji Ge: No. It's not it's not exactly like that part. In the cost, on that page five, if you show the page five Yeah. This is the page this I think this is page five. Right? Yes. The second big bullet from any to any communication, you got the n square, right, as the out of Yeah. Right here. And then I I tried to think about it, like, with this new improvement, are you going to lower down one level of magnitude for the for the communication part or still stay on the n square? Because when I you know, I I look I have I have to acknowledge I haven't read through the document yet, but just based on your presentation, I try to understand. It seems to me that you're trying to address the issue for any to any communication. And then is it an issue or no?
[01:01:36] Teppei Kamata: Yeah. Issue from so in this draft, we are describing IP routing paradigm. For IP routing paradigm, it's a better way to provide any training communication for the scalability perspective. Session based, it needs starting point and end point pair. However, IP routing paradigm needs just a destination destination address for this communication. So this draft is proposing to change this way from the session based to update routing part time.
[01:02:24] Tingji Ge: Okay. Now since you are trying to lower down one level of the order of magnitude from the n squared to n, that is your target. Is that right? Is that right?
[01:02:33] Satoru Matsushima: Yeah.
[01:02:33] Tingji Ge: K. Thank you.
[01:02:34] Teppei Kamata: Yeah.
[01:02:42] Satoru Matsushima: Thank you, So please read the draft and feedback with your comment. I think also think the last call will be good next step, so please provide your feedback.
[01:03:06] Teppei Kamata: Thank you.
[01:03:07] Satoru Matsushima: Thank you.
[01:03:07] Teppei Kamata: Very much.
[01:03:21] Satoru Matsushima: Alright. Next present, Okay. So okay.
[01:03:48] Tingji Ge: Hello? Here. Yeah. Okay. Yeah. Thank you. Yeah. This is regarding some mobile user plan evolution part 5G and six g, actually, more targeting for six g part. This draft, I will acknowledge, it's like a lot of contributions from previous another draft. Yeah. Just let's show you the next one, and then you are going to understand. Yeah. You know, it cost the agenda just different here. Cost in there's a one draft before is on the very bottom of the page is the draft talking about MUP evolution and from 5G to six g. And then we worked really hard, well, at that moment, well, I think for two years maybe, And then discuss, you know, based on what we have, what the 5G has. Are you then playing part and based on something, you know, discussed. And then cost thinking for at that moment, that was, like, two years back. More it's like, okay. The 5G and then evolve to six g. What can be done to either say to improve, to enhance, or simplify, you know, all kind of things? So in the 5G draft, the draft name is on the bottom of the page, composed to say, okay. Well, maybe because they call the gNB there. It's a basic idea is to do some integration of the access node, gNB and the UPF. And the work have been widely presented, discussed. And then what even one time, we asked about two times maybe, ask the group to see whether the group can support it. Too many details there, and then a lot of work actually, you know, related to 3GPP cost these things. Or even if the DMM consider this a useful, that objective or target is still still going for 3GPP. So that is the whole history I'm trying to recapture to sell the things. Two years back, there was. But this one, actually, did not fly because there are lots of debates in the group arguments. Of co-authors, there are supports. So this is just the the history about the the things. So that is the the 5G wall to wall to safety part. And then, yeah, that is the the history. And then the pictures this is for 5G architecture. I'll put here for reference card. Six g is more or less similar, but the base you know, there are still some debate on which one, about the official name, all kind of things. But the more or less architecture can be referenced, know, kind of similar. So to put this picture into your brain, and then, you know, that will be easier for you to to follow through the next couple of slides. Yeah. For the six g UP architecture, that's actually, it's a one of the I think one of 24 k issues are being discussed in 33GPP. Yeah. I think John Keay mentioned that. Right? Yeah. The the things. And then this one, data objective is to improve the UP architecture. And then there's some objective, like, achieve flexibility, scalability, resilience for the support of, you know, amount that we're set of application or traffic patterns. This is, like, very abstract or but I want to achieve something. So these are the key issues and then later displayed key issues into two major tasks. And one is well, I would say it's, like, more like toward the the control plan bar is the the the target is for better multi vendor interoperability as the the CP and the UP, you know, in action things. Well, I'm going to show that part in next couple of slides and then, you know, here just to to give the the bullet to list, you know, the something. And then the second part is more on the UP itself. So, basically, they want to achieve some, like, flexibility, resilience, and scalability. And then the next two lines are very important here. This is the consideration of the UP function capability and the past performance between the core network and the data network. The parenthesis is added by myself just to try to to try try to show something, you know, better for people to understand what is core network in the DMM part. Well, of co-authors, people should and and and well know it. It's it's a wireless six g. Well, so just and the parenthesis to make it more clear. So there are two things. One is, like, inaction between CP and the UP for better multi vendor interoperability. The other part is, you know, for the UP since flexibility, resilience, and scalability. Actually, each word has some meaning to work or requirement behind behind it. So yeah. Okay. So the key issues and then the the key tasks. Yeah. The this one, I know just to show this part is more like the inactions between the CPU p and the remember in a couple of a few slides back showing the 5G architecture there, while you can consider the similar things. Yeah. Just trying to remind people just in case, yeah, in case you you forget this one. And then here no. Sorry. No. No. Okay. It doesn't it doesn't have it. No. No. No. It means, like, the the pointer. Okay. The point does not work. Right? Is that no? See. Oh, it's there. Okay. Okay. Thank you. Yeah. Oh, here does not work. Yeah. Okay. Yeah. That that's the thing, actually. Yeah. The thing I just try to the CPUP part, and then you can look at that n four here, n four interface. It's actually that's why. Just memorize that things. Yeah. The things like I remember the first task to to enhance the CP and the UP in the action in action for better multi vendor operability. You know, the the so far is the SMF. Actually, that is on the control plane part, and the UPF is the user plane part. I would say most majority of the cases, they are provided by the same both are provided by the same vendor. Yeah. Because there are some vendor specific attributes that need to be exchanged. So, like, put some example. Yeah. It does not work here. Yeah. Some example, like, optional features like a DPI, the packet inspection, billing, charging, QS steering, those things depend on vendor specific interpretations. Okay. Here. And then the other, you know, these things will will restrict cost right now if the six g would want to extend. You know? That'll I'm actually the better for operator part, but not sure for for vendor. I'll still there's some, you know, yeah, something behind it. So but the objective is, you know, is there are kind of 5G concerns now for six g objective. How about the two disaggregate the proprietary based the network function copy, and after like, SMF or UPF, still not I remember that picture. Yeah. Show the a few data a a few slides back. So there are some proposals. One is, like, the the buffering CP buffering. Is it like a here. Yeah. On the downlink downlink in this picture, you can check consider from the right toward the left side when the traffic come in, and you you have two places to buffer it. One is on the UPF. No. That is really the UP and the user. And now that actually can be done on the on the control plane part on SMF. So the 5G is so flexible, and now you can call it a powerful or the other the the word might become, yeah, complex complicated. You know? And then lot of features are provided here or there. So even for this one, for the real the data traffic, you it can be buffer on the UPF or on the SMF. But that is a feature. So it's going to complicate it, so where to put it, UPF CP things. The other the other is the second, well, not supporting the constructing, CP constructing the end marker packet. You know? This is I don't want to cover details about the end marker, but the things just like related to, like, roaming, the UE, the roaming, and the UPF got changed and reentered, all kind of things, and then on the downlink. So if during that period and then some traffic packet are in the fly, so in that case, you don't want to loosen. So you are going to do something. And then but you're still going to say, okay. At one moment, on this path, this will be the final packet for for this path. So, basically, you put the end marker. Well and then for the other path, it can wait and until, the other pass see the end marker. Well, I tried to make it simple. And then the the new pass will start to slow down the traffic. So this is more like a general concept of the end marker. By the way, there's a draft that was, like, two years two and a half years back on the end marker in the 5G network. That one, yeah, was was composed by Jeffrey out of myself. Yeah. Here, just to say, okay. Well, there are something should to achieve for multi vendor interoperability. So while it seems like, okay. What what what does that mean for for us, for the DMN part? So here, I just try to say, okay. We benefit deployment of MUP controller since because the the things like if you oh, no. You if really the CP and UPC part, it is it disaggregated things. And then all the lot of signaling things is I would think it's gonna be simplified between the the CP and the UPC. Well, this is still, you know, at the at the beginning. So as I just think aloud I think aloud to see or, you know yeah. Yeah. Just the same part. I try to just see what does six g mean us mean for us in DMM things. This is for multi vendor interoperability. Yeah. The other the other remember, the other tasks that I showed in one slide is the flexibility, scalability, and resilience. Okay? So each word has some meaning behind it. The first one is the flexibility. Yeah. You know, the flexibility is like, okay. How can you achieve a lot of scenarios? And the one particular thing is a a proposal. Yeah. This remember this is still the TR. I think Marco showed the TR 23.801, the six g study of architecture part. There's still TR not yet being standardized, but there's still proposal ongoing right now. So instead of using one type of the UPF, here, we're trying to say, okay. Well, how about the propose another UPF, kind of selling UPFs? And then that one can be a distri can be deployed in a distributed mode. Yeah. So this is actually a callback to what we have proposed in the original 5G, the U MUP draft mode. We said, okay. Well, in that case, distribute UPF or even integrate a GgNBe and other UPS things. But this actually, well, obviously, is different. Here, you have to to make the data clear. This is different from the I-UPF or UPS things. Here, the serving UPF, SUPF, or AUPF, they the proposal is trying to split the functionalities between these two. One, suppose, like like, s e SUPF to just provide some basic functionalities, like AUPF problem provide more advanced things. Actually, there's some examples there to show, like, MOQ. There are some features as being standardizing 5G. The other is, like, connect the UDP, all kind of things. So, basically, you you have one SUPF connect close to the UE and then to pro to provide only basic functionalities, UP functionalities. And then the a the the anchor UPF is a little bit further away and then can we're going to provide more advanced ones functionalities. So here, well, it's just to say, okay. Well, you know, STUPF, the serving UPF does not does not necessarily go through the AUUPF. So the picture just showing there are two ways. You know, one is chain together or connect together as UPF to AUUPF and then toward the PN and the DN, or as UPF can do an interface. So this is the, like, the flexibility, okay, and the UPF distribution. So that is one of the three targets in the second in the second task, flexibility, scalability, and resilience. So here, like, flexibility part. And then the next will be the scalability and the resilience. Okay. So remember, we had the SUPF and the AUPF, those things. Okay. How about the like, we make it in more to scale up? Scale up on one to make it, like, as you have set or you have set things like a like, some idea to say, okay. Well, in this case and then we're going to, like, a load balancing, like, fault tolerance, resilience, and also even for the scalability. Well, of co-authors, in here, we have a bunch of things within within a group. So, yeah, all the pictures now, it is a one by one, and this is the final part. Okay. So now that is the the six g the six what six g are doing, and then thinking what the the idea of impact to six g things. The the first things are this about the the six g emphasize agnostic requirement of the TM, the transport network thing. So, basically, there are no restriction on the transport itself, like, anything. MPLS, SRV six, a metro Ethernet, all kinds of things. The second part is, you know, remember, at the very beginning, say, okay. Scalability flexibility, scalability, resilience with the consideration of the path performance function capabilities between the a n and the d n. So that is very important sentence in that in that task. So here, the the things like so what what does what does that what it implies for IETF things here. So yeah. And in the at the 3GPP, I mentioned the the here, 23 dot a one 23 dot a zero one, it mentioned, okay. What is the the PN capabilities? So, actually, the the latency, bandwidth, load, packet loss, all kind of things. You know? That thing actually is like it's good for the CATS. The CATS technology is here. Or it's actually, it's there. The 23 the one, the six g architecture study, it does explicitly mention about the CATS things, and then that's being referenced. Okay. The other thing, I think Marco has already mentioned about the DMM MTS draft. You know, in in the $23 EVA eight zero one, it said, okay. Well, the six g, the TR for the controller in actions. And then there are something, you know, can be referenced in that DMM MTS draft. Okay. So that yeah. All all good things. And, also, there are some still ongoing proposals regarding the GTP-U of Srv6. It's like there are two ways, of co-authors. In a 5G discussion, that was, like, many years back regarding whether SRv6 can be used to replace GTP-U, but there are some debate there. Now it it resurfaced. You know, there are two ways. One is just the for the for the overlay solution, I know it's it's there. It's okay. Well, not the not much obvious. But the other side is the native. So that is actually resurfaced. Yeah. So yeah. So this is something, yeah, regarding the the inaction or comparison on GTP-U versus SRv6. And then I think that is the all. You know, here is still ongoing. You know, twenty three dot eight twenty three dot eight zero one is still ongoing, not yet. I think it's going to be finalized by by the end of year. A junkie just is that? Yeah. Yeah. By the end of the year. So this is very dynamic or fluid situation right now for the of the safety part. So this drug, for sure, is going to evolve based on the the the changing of progress of the six g study. But along the line, along all the proposals, all kind of things and thinking, you know, this this six g UP architecture will introduce more work to the DMM, of co-authors, to some other working group like here. I mentioned the podcast things and even the SRV6 Spring are kind of for the the the part. So it's good and something to be considered for DMM. And I think that is yeah. That is all. Yeah. Thank you. Hopefully, not a lot.
[01:22:29] Satoru Matsushima: Thank you, Tenji. Question, clarification. One question from my side. Do you capture the discussion with the, or do you present your proposal?
[01:22:51] Tingji Ge: Oh, this is the proposal from the 23 the 33GPP23Dot801.
[01:22:58] Satoru Matsushima: Okay. You capture the discussion. Yeah.
[01:23:00] Tingji Ge: Yeah. Yeah. This this, I think, well, up to June. Yeah. I think the latest virtual meeting, haven't because maybe but not much difference, I think. If I'm Raj, just like I have a correct idea.
[01:23:16] John Kaippallimalil: I think that's right. I mean, the main things you mentioned over there are the flexibility, scalability, and reliability levels. But as you mentioned, there's no this is a study, obviously.
[01:23:28] Tingji Ge: Yeah. That's right. Yeah. So still, the value fluid right now. So, yeah, so it's by the end of the year, probably, we can get a TS. Yeah. Yeah. Thank you.
[01:23:39] Satoru Matsushima: Thank you. Okay. Go ahead.
[01:23:46] Participant: Can you go to the last slide where yeah. This one. So the first point, 60 emphasize agnostic requirement of transport network. And then at the very bottom, there is a still ongoing discussion about SRv6 to natively replace GTP-U. So these two points kind of sound, like, contradictive. Have we because if they emphasize agnostic requirement of transport net network, then it sounds like that's they really should be going the the overlay model. It's a GTP-U transported over s r SRV six, not that SRV six replacing the GTP-U.
[01:24:31] Tingji Ge: No. So the things like remember about John K also mentioned here, that's the ongoing part. Right? So they say, okay. Now for the key end, the transport technology things, well, you can use whatever. You know? It's like overlay. Right? Yeah. But but the things like if and by moment, it's being decided, well, SRv6 can be natively applied. In that case in that case, it's it's gonna be SRv6 to replace. Yeah.
[01:24:57] Satoru Matsushima: Okay. In that sense, I think if CPV adopts SRv6 as a user plan, is SRv6 over MPLS makes sense?
[01:25:08] Tingji Ge: SRv6 over what?
[01:25:09] Satoru Matsushima: MPLS. Because the SRv6 Okay. Be a user plan.
[01:25:15] Tingji Ge: Then In that case, can you
[01:25:17] Satoru Matsushima: the agnostic requirement be here. So then
[01:25:21] Tingji Ge: Have you used that?
[01:25:21] Satoru Matsushima: R v six itself is not the transport technology. So then MPS should carry the SRv6. It's really contradicted.
[01:25:31] Tingji Ge: Yeah. In that case, well, like, SRMQS.
[01:25:36] Satoru Matsushima: Yeah. SRMQS itself is a plan, then MPS need to be carried over their services.
[01:25:42] Tingji Ge: Okay. Still, like, being discussed there. So we don't
[01:25:46] Satoru Matsushima: Okay. Okay. Great.
[01:25:47] Tingji Ge: I cannot answer that part, but it's still okay. I think it's good, actually. The discussion in 33GPP is good for us.
[01:25:53] Satoru Matsushima: Sure. Sure.
[01:25:53] Tingji Ge: Yeah. Yeah.
[01:25:54] Satoru Matsushima: So Of co-authors.
[01:25:55] Tingji Ge: Yeah. Good job.
[01:25:56] Eric Klein: Yeah. From China Mobile. You mentioned the two proposals. One is the the GTP-U. I think maybe that is overly through I seven six. The second one is I seven six replace GTP-U.
[01:26:12] John Kaippallimalil: Yeah.
[01:26:13] Eric Klein: Then there may be another proposal. Maybe we just partially replace GTP-U. You know, there are several interface for six g, at least for 5G. But, you know, some of interface, if you want to replace GTP-U, it's really hard. Yeah. But some of the time, maybe it's easier and it's necessary because when you want to integrate the computing to six g, that's reasonable to introduce service interface, especially the service orientated interface to such as a six g more flexible solution. Do do you think that is reasonable? Yeah. The the the thing
[01:27:16] Tingji Ge: is here right now. I would say your proposal are very meaningful. And but the thing is here. This is remember. They have been discussed in the 3GPP things. And then if you really want to introduce, like, there are three ways in instead of only two things, you know, have to bring contributions to there. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.
[01:27:45] Eric Klein: Then, you know, here, we are network guys. Right? And then we understand that as of '6 or as a network technology much better thaN3 g p p guys. So I think we should give some reasonable solutions proposal to them. Yeah. It may be. Thank you. Okay. Sure.
[01:28:07] Satoru Matsushima: Thank you, Okay.
[01:29:09] Xiaohu Xu: Okay.
[01:29:10] Satoru Matsushima: So I will give you the control. Oh,
[01:29:17] Xiaohu Xu: okay. I got it.
[01:29:21] Satoru Matsushima: Okay. Please.
[01:29:25] Xiaohu Xu: Oh, hi. I'm from China Mobile on behalf of my. And our topic is requirements of SRv6 for six g user play. As three 3GPP has formally launched the six g standardization work, the requirements for six g transport networks are becoming increasingly clear. S r v six is well positioned to satisfy this diverse technical demands, which is exactly why we submit this draft recently. Our objective is to propose routine native connectivity solution that can be natively deployed across future six g six g networks. Sorry. I can't control my slides.
[01:30:42] Satoru Matsushima: Let's get back to your stride. Give me a sec. Can't go through.
[01:31:03] Tingji Ge: Mhmm. Mhmm.
[01:31:08] Satoru Matsushima: Wait a minute. Now you get control. Okay.
[01:31:43] Xiaohu Xu: Oh, okay. Let's start with the drawbacks of existing GTP-U architecture, which has four limitations for six g. First is fixed forwarding pass. Rules are fixed once a session is created. Network cannot adapt to real time congestion or dynamic service queues changes leading to inefficient routing and higher end to end latency. Second is high reconfiguration latency. Any mobility events or network failure triggers long control planes signaling to rebuild tunnels. The service interruption is too long for URLLC c six g applications. Third is single dimensional service identification. System only relies on basic cues markers like QCI, which cannot express the multidimensional needs of immersive six g services. The last cost forwarding granularity, our forwarding rules work at the PDU session level via DNN and the S-NSSAI. There is no native way to separate or prioritize individual flows within one user session. Based on six g typical service scenarios, we abstract six six g user planning capabilities covering flexibility, reliability, efficiency, and intelligent OAM. First one is dynamic topology and seamless scheduling. The network must adapt to constantly changing topology and spot seamless path switching to guarantee service continuity and faster failure recovery. Second is fine grid queues and traffic isolation. We need the process traffic classification plus strict logical and physical isolation. So mission critical services get prioritized and diverse as always can be fully guaranteed. Third is fine, green queues, and traffic isolation. Third one is deterministic, reliable forwarding. Had upper bounce on latency jitter and packet loss are required, which lays the foundation for URLLC services. And the fourth one is efficient transmission and the flow aggregation. We need to reduce packet header or header, aggregate gates massive concurrent flows, and cut down device state state consumption to boost overall throughput and scale scalability. Next, application semantics inbound carriage. We can carry application contacts directly inside data packets. This lets the network read user service intent and make optimized forwarding decisions decisions automatically. Last is native. We inbound telemetry or inbound OAM. We can collect hop by hop real time performance metrics across the Intel forwarding paths. This phase network digital twins and enables autonomous network optimization. Next, the s r r six delivers all the capabilities about by introducing network programmability, which falls into three layers, pass, service, and application programmability. For the pass programmability, we use an older list of states to explicitly define the end to end forwarding pass decoupled from hop by hop routing. It can support real time dynamic route optimization, faster reroute for fault protection, and seamless past updates without teardown set sessions. For service programmability, it can embed the network slicing and the service function training instructions directly into the packet header. The forwarding notes can process service logic while packets are in transit. Also, it can achieve per-flow differentiated scheduling, strict slice isolation, and flexible dynamic service composition. Exactly on what six g services require. The last application programmability, it also can insert application specific metadata inside of the packets, such as AI compute load indicators or latency budgets, enabling network proactively adjust routes and the resource allocation based on real application demands. Next page is about SRv6 control plane coordination. S r v six pass compute computations say the allocation management and the policy might be rely on close coordination between the core network control play, such as SMF, AMF, or PCF, and the transport network control play in like controller. We need for basic interactions. First, end the centralized pass computation and policy provisioning. The controller collects the full network status, calculates SRv6, say the least, and forwarding rules, and pushes all policies to the ingress UPS in one consistent transaction. Second is dynamic partial pass updates. When users move or compute resources shift, we only update affected segments of say, the list instead of rebuilding the whole policy. Survise SLA to say the MUPping, preconfiguration translation betweeN3 3GPP use parameters and the SRv6 header indicators. So every new flow instantly gets matching s r a forwarding rules. The last continuous state synchronization between SMF and the transport controller to keep session and set the making consistent across call and the transport domains. About next steps, as the six g user play architecture evolves, we will identify more new requirements for SRv6 as the unified user plan forwarding protocol. We hope to propose standardized extensions to upgrade SRv6 capability for next generation mobile systems. Welcome more comments and feedbacks to put this work forward. Thank you.
[01:40:32] Satoru Matsushima: Thank you. Any question, clarification, or comment? John? No?
[01:40:50] John Kaippallimalil: With the caveat that I haven't fully read the draft, I had a question if you've considered roaming networks and SRv6 between them. I wonder if you'll run into issues of multi domain aspects. So just wanted to ask that.
[01:41:10] Xiaohu Xu: Oh, okay. I I will analyze the roaming scenarios.
[01:41:32] Satoru Matsushima: Any other comment from the room? Thank you, Xiaohu. I think the capturing the discussion in the 33GPP for succeed is really valuable for us. So if you can continue to capture the the discussion, the studies of the SRv6 proscans and bring your study to the the the DMM really valuable. So and change change work could also related to that work. So I think it'd be nice if you you both of you can work together and and bring the discussion and study to the to the DMM.
[01:42:35] Xiaohu Xu: Oh, okay. Thank you. We will coordinate to each other and put this work forward with.
[01:42:53] Eric Klein: So, mister Taro, I I think we have a lot of discussion here about data plan for 60. And is that possible we can write some of the lessons to three 3GPP to in info line what we are discussing discussing here, I I think that may be valuable for 3GPP guys.
[01:43:28] Satoru Matsushima: Mike, please. Michael, please.
[01:43:30] Eric Klein: I I think it maybe we should run the first step. Yeah. Yeah.
[01:43:35] Satoru Matsushima: Yeah. Please.
[01:43:38] Eric Klein: K. Thank you. Yeah.
[01:43:44] Satoru Matsushima: Okay. Any other comments? Okay. This is the last slot. So let's close the meeting and see you in San Francisco. Thank you.