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]> 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]> > *Sent:* Wednesday, October 29, 2025 11:35 AM > *To:* Satoru Matsushima <[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) > > > > 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]> 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]> > *Sent:* Friday, October 24, 2025 4:52 PM > *To:* Satoru Matsushima <[email protected]> > *Cc:* [email protected]; [email protected]; > [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]> 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] > 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] > >
_______________________________________________ dmm mailing list -- [email protected] To unsubscribe send an email to [email protected]
