[DMM] Re: WG Last Call: draft-ietf-dmm-tn-aware-mobility-22 (Ends 2025-10-30)

[Satoru Matsushima <[e-mail]>]

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