John, Thanks for addressing my comments. The revised draft is good. I support the WGLC.
Linda From: Kaippallimalil John <[email protected]> Sent: Tuesday, November 4, 2025 6:22 AM To: Linda Dunbar <[email protected]>; Satoru Matsushima <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: RE: [DMM] Re: WG Last Call: draft-ietf-dmm-tn-aware-mobility-22 (Ends 2025-10-30) Hi Linda, Thank you for the comments and support. The authors have added text in the security section to address the comment regarding security and UDP port numbers, and that section 6 is brief. Revised to address the nits (misspelling and common term). Slice provider network, transport network and TN slice provider are all revised to TN slice provider. “Mobility aware” was a comment that was addressed during previous reviews. The document states the following in section 1, Introduction to be clear what mobility awareness means here: “Following UE handover, the S-NSSAI is mapped seamlessly to the corresponding GTP-U (or UDP encapsulated GTP) source port number of the newly attached network and can be considered to be “mobility aware” Regarding roaming, the mapping of slice assigned to a UE (PDU session) that is roaming is handled by agreements between the home and visited PLMNs. The mapping is then handled on that basis and transparent to the mechanisms described in this document. No changes are needed in this case as roaming itself is beyond the scope of this draft. Please see new version/diff: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-dmm-tn-aware-mobility-23&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7Ca53923a3718f4b44e9b608de1bad41bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638978628121984873%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rRuK6uT3gVgtpAK0YvjXQ5IuG%2FC8YnGdGIZI1BQfvXg%3D&reserved=0<https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmm-tn-aware-mobility-23> Best Regards, John From: Linda Dunbar <[email protected]<mailto:[email protected]>> Sent: Monday, October 27, 2025 7:33 PM To: Satoru Matsushima <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: [DMM] Re: WG Last Call: draft-ietf-dmm-tn-aware-mobility-22 (Ends 2025-10-30) I support the WGLC of the draft with the following comments: * The document repeatedly says “mobility-aware” but does not explicitly define how mobility is detected or maintained across TN slices. Would be nice to add a short paragraph explaining how the UDP port-based mapping persists or updates across handovers, and how synchronization with 5G control-plane signaling is ensured. * draft-jlu-dmm-udp-tunnel-acaas-00 and draft-ietf-opsawg-teas-attachment-circuit-20 are both works in progress; if these are normative dependencies, the IESG may block publication until they stabilize (which can be years.. painful!) * Section 6 is too brief. It only references RFC 9543 and says configuration is “explanatory,” without addressing the risk that UDP port numbers are easily spoofed. Suggest adding discussion of: a) Attack surface from forged source ports; b) Need for integrity between 3GPP node and PE (e.g., via ACLs or IPsec); c) Whether slice mapping relies on trusted provisioning channels. * It’s not clear how the PE learns the mapping between UDP port ranges and S-NSSAI dynamically if the UE roams. Nits: * Throughout the document, there are mixed usage of “slice provider network”, “transport network”, and “TN slice provider”. Do they mean the same thing? If yes, suggest using one throughout the document for consistency. * Section 3.2: typo: “maybe realized in an NSS at that a location.” -> “may be realized in an NSS at that location.” * Section 3.3: typo: “EP_Tansport” -> “EP_Transport.” * Section 6: typo: “authentication” -> “authentication”. Best Regards, Linda Dunbar From: Satoru Matsushima <[email protected]<mailto:[email protected]>> Sent: Friday, October 24, 2025 2:52 PM To: Satoru Matsushima <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [DMM] Re: WG Last Call: draft-ietf-dmm-tn-aware-mobility-22 (Ends 2025-10-30) DMMer, Let me remind you that the mobility-aware transport draft is now in WGLC. It will end on Oct. 30, so please review the draft. You can use this thread to send your feedback. Cheers, --satoru On Thu, Oct 16, 2025 at 9:09 PM Satoru Matsushima via Datatracker <[email protected]<mailto:[email protected]>> wrote: Subject: WG Last Call: draft-ietf-dmm-tn-aware-mobility-22 (Ends 2025-10-30) This message starts a 2-week WG Last Call for this document. Abstract: Network slicing in 5G enables logical networks for communication services of multiple 5G customers to be multiplexed over the same infrastructure. While 5G slicing covers logical separation of various aspects of 5G infrastructure and services, user's data plane packets over the Radio Access Network (RAN) and Core Network (5GC) use IP in many segments of an end-to-end 5G slice. When end-to-end slices in a 5G System use network resources, they are mapped to corresponding IP transport network slice(s) which in turn provide the bandwidth, latency, isolation, and other criteria required for the realization of a 5G slice. This document describes mapping of 5G slices to transport network slices using UDP source port number of the GTP-U bearer when the IP transport network (slice provider) is separated by an "attachment circuit" from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping defined here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. File can be retrieved from: https://datatracker.ietf.org/doc/draft-ietf-dmm-tn-aware-mobility/ Please review and indicate your support or objection to proceed with the publication of this document by replying to this email keeping [email protected]<mailto:[email protected]> in copy. Objections should be motivated and suggestions to resolve them are highly appreciated. Authors, and WG participants in general, are reminded again of the Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 [1]. Appropriate IPR disclosures required for full conformance with the provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. Sanctions available for application to violators of IETF IPR Policy can be found at [3]. Thank you. [1] https://datatracker.ietf.org/doc/bcp78/ [2] https://datatracker.ietf.org/doc/bcp79/ [3] https://datatracker.ietf.org/doc/rfc6701/
_______________________________________________ dmm mailing list -- [email protected] To unsubscribe send an email to [email protected]
