Hi Satoru, All, Thank you for the detailed comments and feedback.
New version 24 posted and implements the changes suggested: * In 3.1, revised end-user (UE) sessions to text with PDU sessions. * In 3.3, revised ‘that signaled’ to ‘S-NSSAI signaled. * In 3.2 revised NSSAI to SST:SD (see details in diff). * Also removed reference to RFC 8519 (not used) and revised I-D.ietf-opsawg-teas-attachment-circuit to RFC9834 Link to diff: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-dmm-tn-aware-mobility-24&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C079122dd094a4ec5e40208de3374bf9c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639004773744388437%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Wyqkn2D2IKliTM%2BtMR%2BZfuqJPPLSPULQvEdgLXdJI1g%3D&reserved=0<https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmm-tn-aware-mobility-24> Best Regards, John From: Kaippallimalil John <[email protected]> Sent: Saturday, November 29, 2025 11:37 AM To: Satoru Matsushima <[email protected]> Cc: Xavier de Foy <[email protected]>; [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 Satoru, Thanks, that’s a good catch – you are correct. It should be SST(8)+SD(24) format of (S-)NSSAI. I wonder if a notation like below consisting of NSSAI = SST(8):SD(24) would be easier to read in the draft. NSSAI = 000A --> 0x02:0x0A (URLLC service, customer A), NSSAI = 000B --> 0x01:0x00 (eMBB service, all customers/locations) NSSAI = 000C --> 0x03:0x0C (MioT service, customer C) Best Regards, John From: Satoru Matsushima <[email protected]<mailto:[email protected]>> Sent: Thursday, November 27, 2025 6:39 AM To: Kaippallimalil John <[email protected]<mailto:[email protected]>> Cc: Xavier de Foy <[email protected]<mailto:[email protected]>>; [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) Thanks John, > It would be good to revise to realistic services SST = 1 (eMMB), SST = 2 > (URLLC) and SST = 3 (MioT). That sounds good. So the example values denoted as 200A/1000/300C follow SST(8)+SD(24) format of (S-)NSSAI. Is that correct? For me those values look 2 bytes in hex. Where are the remaining 2 bytes? Please correct me if I'm wrong. --satoru On Wed, Nov 26, 2025 at 3:09 AM Kaippallimalil John <[email protected]<mailto:[email protected]>> wrote: Hi Satoru, All, Thanks for the review and pointers. - Section 3.1: Change /end-user (UE) sessions/PDU sessions/ and consider describing the meaning of "PDU session" at its first occurrence. In section 1, PDU session has already been defined “A PDU session in 5G is a logical connection that provides a path between a User Equipment (UE) and a data network such as the internet”] Will revise end-user (UE) session to PDU session in 3.1. - Change /to that signaled for the PDU session/to the S-NSSAI signaled for the PDU session/ Will revise. There is one other change that would help (this is sort of triggered from an LS exchange on slices in this November 3GPP meeting): In 3.2 and 3.3, the example NSSAIs that consist of SST (Service Slice Type) and SD (Slice Differentiator) is not accurate. It shows 3 different services A, B, C with the same SST (“0” ). It would be good to revise to realistic services SST = 1 (eMMB), SST = 2 (URLLC) and SST = 3 (MioT). That would change the (S-)NSSAI values in Figures 2 and 3 as follows (NSSAI consists of SST= 8 bit field, followed by SD =24 bit field) NSSAI = 000A --> 200A (URLLC service, customer A), NSSAI = 000B --> 1000 (eMBB service, all customers/locations) NSSAI = 000C --> 300C (MioT service, customer C) This would require some revision in the of 3.2 to align with the above change. No change in 3.3 other than revising 000B --> 1000. Note that this is only change of an example in 3.2 and does not in any way affect the logic of mapping proposed in the draft (i.e., NSSAI to UDP port (range) is a direct map). If the group agrees, I would like to make this additional change. Best Regards, John From: Satoru Matsushima <[email protected]<mailto:[email protected]>> Sent: Tuesday, November 25, 2025 8:05 AM To: Kaippallimalil John <[email protected]<mailto:[email protected]>> Cc: Xavier de Foy <[email protected]<mailto:[email protected]>>; [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) Hi John, Could you please confirm if you plan to address the following specific comments from Xavier de Foy? - Section 3.1: Change /end-user (UE) sessions/PDU sessions/ and consider describing the meaning of "PDU session" at its first occurrence. - Change /to that signaled for the PDU session/to the S-NSSAI signaled for the PDU session/ I was unable to find the resolutions for these particular points in the latest diff and your slides in the last DMM meeting. Thanks, --satoru On Tue, Nov 4, 2025 at 11:22 PM Kaippallimalil John <[email protected]<mailto:[email protected]>> wrote: Hi Xavier, Thank you for the comments and support. Please see the new revision that implements the suggested changes below. Link to 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: Xavier de Foy <[email protected]<mailto:[email protected]>> Sent: Wednesday, October 29, 2025 11:35 AM To: Satoru Matsushima <[email protected]<mailto:[email protected]>>; [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 publication of draft-ietf-dmm-tn-aware-mobility and provide a few minor comments below, for the authors' consideration. - #1: /map a 3GPP slice to a slice in an IP transport network provider/map a 3GPP slice to a slice in an IP transport network/ -OR- /map a 3GPP slice to an IP transport network slice at a provider edge/ - #3.1: /end-user (UE) sessions/PDU sessions/, because the term PDU session is used multiple times in the document already. - Note: consider expanding the term UE as User Equipment in the first occurence of the term in the draft. - Note: consider describing the meaning of PDU session at the first occurence of the term. - #3.3: consider adding text to define what EP_transport is. E.g., /3GPP user plane nodes (gNB, UPF) are provisioned with GTP transport interface information parameters in [TS.28.541-3GPP]./3GPP user plane nodes (gNB, UPF) are provisioned with GTP end point transport (EP_transport) interface information parameters in [TS.28.541-3GPP]./ - #3.3: a few sentences could be clarified a bit,I try illustrating below a few points. - "Each EP_Transport is configured with ATTACHMENT_CIRCUIT containing UDP source port number/range for each of the slices (S-NSSAI) supported by the 3GPP user plane node." Maybe: "Each EP_Transport is configured with an ATTACHMENT_CIRCUIT containing UDP source port number/range corresponding to a slice (S-NSSAI) supported by the 3GPP user plane node." - "This S-NSSAI in the user plane setup can be used to associate with the previously configured EP_Transport information per S-NSSAI." Maybe: "This S-NSSAI in the user plane setup can be associated with one of the previously configured per-S-NSSAI EP_Transport information." - /to that signaled for the PDU session/to the S-NSSAI signaled for the PDU session/ - #4: About the paragraph "In some E2E scenarios, security is desired granularly...", I was wondering if the text could cover something more general than security, e.g., "In some E2E scenarios, additional path characteristics may be desired in the underlying transport network, such as security characteristics.". The rest of the paragraph may be adapted correspondingly, if you agree with this comment. One example of non-security characteristic that comes to mind is regulatory/legal, e.g., the physical location of the path (and this does not need to be spelled out in the text, this is just for illustrating where my comment comes from). - #6: /authenticaiton/authentication/ Best Regards, Xavier On Wed, Oct 29, 2025 at 7:23 AM Kaippallimalil John <[email protected]<mailto:[email protected]>> wrote: draft-ietf-dmm-tn-aware-mobility provides a solution to support the capabilities offered by 5G slices across IP transport networks that backhaul the traffic. As an author, I believe this draft is ready for publication. Best Regards, John From: Satoru Matsushima <[email protected]<mailto:[email protected]>> Sent: Friday, October 24, 2025 4: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: 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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ dmm mailing list -- [email protected] To unsubscribe send an email to [email protected]
