Hi John, many thanks for your constructive comments and suggestions.
Please see for feedback inline [ml]. From: Kaippallimalil John <[email protected]> Sent: Montag, 22. September 2025 15:11 To: Distributed Mobility Management Discussion List <[email protected]>; Marco Liebsch <[email protected]> Subject: draft-liebsch-dmm-mts-03 review Hi Marco, All, The draft identifies a gap/problem in 5G systems and the need to (re)select and steer flows. This draft can provide value and insight into a complex area. There are gaps currently as 5G/3GPP does not fully cover the N6/IP segments of the E2E path. However, the draft describes too much of existing/standards (using different names and terms), and it is not easy for a reader to distinguish the gaps from already specified standards. A couple of suggestions: 1. Since the architecture in section 4 is 5G, why not use the same terminology/refer to TS 23.501. And add concepts that are new. This will make the text shorter and allow readers to see clearly what the gaps are. For example, what part of the architecture in Figure 4 is covered in 23.501, and what isn’t (same for many others). [ml] The draft proposes a solution that applies to a general mobile communication system architecture that also 3GPP follows. Most relevant for the draft is the mobile architecture’s entry points for user- and control-plane, which we depict in the reference architecture of a mobile communication system. Intention from the very beginning was to keep the draft independent of 3GPP but complementary and compatible with a general function architecture of mobile communication systems. However, applicability and compatibility with the 3GPP architecture is of course wanted. Keeping the draft independent of the current 3GPP specs was also requested from various sides. We can discuss if and how it could be addressed for information, if needed. 2. Regarding the gaps, there are architectural principles and options in section 5 + but the draft does not outline the tradeoffs or say when one option is preferrable over the other. For example: if services/network require to only maximize bandwidth utilization vs. guarantees on latency/bandwidth. And, resilience, complexity (e.g., O(n^2) vs O (n), scalability, etc. [ml] Good point, we will add more details about when a particular deployment is preferrable and where the tradeoff is. Also for the operational details we plan to add more details in the next revision. Another aspect is the relation between this draft and CATS. Where are they complementary, or an alternative and the rationale for choosing among these methods of steering. [ml] We presented the MTS draft in CATS during IETF123 to make the group aware and explained where is complements CATS and how their architecture can use it. It’s between the CATS control plane and the mobile communication system in case CATS applies not only to compute-aware traffic steering but if they need to inter-work with mobile communication systems. We offered help in capturing this in their work and documents, e.g. in terms of clear interfaces and synergies. Some detailed comments: a. Abstract & section 4.1 refer to “two architectural principles” but is not clarified what it is until much later. The reader must read until section 5 to understand what it is about steering. It should be stated much earlier and described later for easier reading. [ml] Valid point, we’ll capture the aspects of later details and differences coming with these options earlier in the draft. Thanks. A result from adding more specifications and details in the back and not checking if these are properly introduced at the beginning of the document 😉 b. Section 2 / Introduction: discusses “ how existing or new IETF technology can serve as enabler to accomplish service continuity for a mobile user in such agile and dynamic system by means of controlled treatment of a mobile user's end-to-end traffic for steering, with an option to extend for advanced treatment policies, such as traffic engineering.” Many concepts, and options make it hard to follow: (1) the scope has steering and “advanced treatment policies”, and steering policies. What exactly are the differences? [ml] Thanks for the hint, we will be more thorough in the use of these terms and include clarifying details once to let the reader know how we use these terms in the context of the draft. (2) does advanced treatment policies refer to QoS aspects? [ml] Yes, steering is the primary objective but early when discussing this work there were views that QoS should be covered. So, beyond steering, advanced policies can address QoS, metering, etc. We will be more clear in a revision. (3) steering and service continuity: does user mobility trigger steering, or does measurement on path trigger steering, or both? [ml] it’s both and even beyond that. We see various triggers that require steering and want to clarify this in the use cases section. User mobility is typically handled by the mobile communication system, keeping a stable user plane anchor point. We do not touch this. Now and in the future, more re-configurations are/will be supported by mobile communication systems that may re-locate such anchor point or use multiple anchor points concurrently in the view of route optimization between a mobile device and its multiple used service in distributed data centers. Also a change in the transport network, e.g. failure or movement of a data plane node may require updated steering policies. Please consider that the draft wants to complement a mobile communication system by means of inter-working and not interfere with it. (4) The draft has many terms like “flexible deployment”, dynamic re-configurability, complexity which can be understood in different ways. c. Section 4.2. MCS Proactive UPA relocation : “proactive” is a bit confusing and depends on perspective. (1) “Due to mobility, the MCS may relocate the mobile user's UPA from UPA1 to UPA2”: that would seem more reactive? [ml] From the viewpoint of the transport network and the MTS controller it’s proactive by the mobile communication system, while the transport network needs to react. Scenario per Sec. 4.3 is reactive, where the MTS controller or further instance on the path towards the data network forces a change in traffic steering, and the mobile communication system needs to react according to the MTS controller’s advice. Let us again parse the description and we’ll try to be clearer here in case it’s confusing. (2) “In case the user's IP address needs to continue only as long as the data session with ASF1 takes ..” How does UPA know how long the session lasts? [ml] You are right, we take an assumption on the transient use of a user’s IP address before it’s deprecated and at some point in time the UE starts using a newer address. Temporarily it may keep both addresses until sessions, that use the older address, terminate. A case often discussed in the past, while details about its implementation differ. For this draft such control is considered out of scope. Let us parse this use case again and see how much details can be assumed as they are not relevant for MTS between a user plane anchor and the data network, and what else we need to consider in the draft. This is something we can investigate and address in the information/data model that the draft defines, in case associated semantic is useful on the addressed interface. d. Section 4.2 “In order to keep routing paths short and latency low, the ASF may be relocated from ASF1 to ASF2”. How does ASF /data network know how to do this? Does MCS proactively relocate the UPA (UPA1 -> UPA2) based on some measurements of the path UPA1 – ASF1 and expect to have better performance after the move UPA2 -> ASF1? [ml] Similar to the above, it may be negotiated and controlled within or between data networks. 3GPP addressed such cases in the past by means of single/multiple Application Function (AF) per Application Service (AS), and inter-actions between them to coordinate such relocation. Also, in the past discussion about technical enabler for edge computing, relocation of serving edges has been discussed. Same here, let us see and discuss what we need in the information/data model for the MTS interface to support such case, and then we should add it. Please consider we plan to have a clear scope of the interface that we want to support and in particular an interface between the MTS Controller and any data network services is out of scope. Maybe another touchpoint with CATS, which has inter-working between compute sites and a CATS control plane, according to my knowledge. e. Section 4.4: “A MCS provide may deploy distributed UPAs in order to shorten the route and resulting latency for the communication between two mobile users” Why is there a need to move UPA for shorter paths? Isn’t it possible to have a routed network (with DPNs) that select the shortest/lower latency path etc. The problem seems to be that the UPA is not distributed enough (that one has to move from UPA1 -> UPA2 to get a shorter path to UPA3) [ml] The rationale behind this is when the mobile communication system has far-edge kind of distributed user plane anchors, in an extreme case anchor co-located with radio base station (similar to the ANUP draft in DMM). Here the anchor should be relocated in alignment with a handover between a user’s radio base station. DPN associated with an anchor needs steering rules to forward data plane packets to the new, re-located user plane anchor of its communication peer. But I understand and agree that more clarifying description for this use case is needed, e.g. by means of added incremental steps with description to the text. We’ll implement this in the next revision. f. Section 5:/ deployment options. Between the different options what is the trade-off in terms of scale and complexity (of provisioning/maintaining the paths) See overall comments also. [ml] Understood and confirmed as part of your comment (2) above. We will introduce the rationale behind these options earlier in the draft and details about advantages and constraints with each options in Sec. 5. Again, many comments and suggestions that help us improving the document. Many thanks, John. Best regards, marco Best Regards, John
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dmm mailing list -- [email protected] To unsubscribe send an email to [email protected]
