Hi Sri, Thank you for taking the time to review the draft and for the thoughtful feedback. Your points are well taken. Some of the statements about the existing 3GPP architecture are too broad and need to be qualified, particularly where the outcome depends on the deployment and application requirements.
We will review the draft as a whole, not just the examples you highlighted. We will also consider how best to structure it so that it clearly presents the applicability and benefits of SRv6 MUP without overstating limitations of existing approaches or implying changes to 3GPP-defined interfaces. I will discuss the scope of the revision with Satoru-san, the other authors, and people familiar with the 3GPP architecture. Given your feedback, I agree that it would be better to revise the document before proceeding with WGLC. We will follow up with an updated draft. Thank you again for your guidance and for being willing to issue the Last Call. Best regards, Teppei ________________________________ 差出人: Sri Gundavelli <[email protected]> 送信日時: 2026年10月22日 17:12 宛先: Teppei Kamata (tkamata) <[email protected]> CC: [email protected] <[email protected]>; [email protected] <[email protected]> 件名: Re: WGLC request for draft-ietf-dmm-srv6mob-arch-04 HI Teppei-san, & Authors, Thank you for your email. I did a quick scan of the document and I noted few issues. Given that IETF is not chartered to redefine SDO interfaces, we have to be careful in making sure the draft is not stepping on 3GPP territory. Meaning, we can promote new architectures and technologies in an access agnostic manner and provide applicability statements to a given access architecture. In the process, its better to promote the SRv6 based architecture in a positive manner, state its benefits etc, but have to be slightly careful not to say the current 3GPP system is broken, or use of phrasing indicative of a “compromised” architecture that is in place. I tend to think the draft requires one good edit; structural edit and also some editorial work. Many of the statements on the limitations of current architecture have to be qualified or removed. For example: > Less suited for any-to-any communication * Less suited for edge/distributed computing * Less suited for fixed and mobile convergence (FMC) / wireless- wireline convergence (WWC) * Limited control of the underlay path > As for FMC/WWC, there is currently a coordinated standardization effort between 3GPP WWC [TS.23316] and BBF [BBF407]. However, the idea is to anchor even wireline traffic in the mobile packet core, which compromises simplicity and scalability. > Also, if the UPF is distributed, seamless handover has to be compromised. These statements have to be qualified. It depends on many things, where the application services are etc. More importantly, please try to think how to present this in a good way, where the draft will be seen a benefiting the IETF and 3GPP community. I suggest talking to Satoru-san and few 3GPP experts. I am happy to issue the LC, but I tend to think this needs more work. Please let me know. BR! Sri On Oct 21, 2026, at 6:14 AM, Teppei Kamata (tkamata) <[email protected]> wrote: Hi Chairs, Following the discussion at IETF 126, we have uploaded revision -04 of draft-ietf-dmm-srv6mob-arch. This revision expands Section 2 to clarify the O(N²)-to-O(N) scalability comparison raised during the session. In particular, it explains the respective roles of 3GPP session management and the MUP control plane, and clarifies that the comparison concerns connectivity state for optimized any-to-any communication. The core architectural discussion remains unchanged. We believe the draft is ready for Working Group Last Call and would like to request that the WG start WGLC. We also recall your comment that additional reviewers would be helpful. Please let us know if you would like us to seek further reviews before starting WGLC, or if there is anything else we should address. Draft: https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6mob-arch/ Best regards, Teppei
_______________________________________________ dmm mailing list -- [email protected] To unsubscribe send an email to [email protected]
