Hi Med, all, (For some reason, I did not receive the e-mail, and I'm using a copy forwarded to me by Luis)
The authors have revised the draft to address /resolve the DISCUSS comments: * Revised title of draft to: Mapping 5G slice to Transport Network slice with UDP Source Ports References to "mobility awareness" is removed in both occurrences in the draft. * Revised to add Normative References section. Moved RFC9543, RFC9834, RFC9889 and TS28.541 to normative references. There are a few other changes to address comments from tsv-art and I'm replying separately on that. Links: URL: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-dmm-tn-aware-mobility-29.txt&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C5b0ddc0f5eab41ca9e1c08deed7d63e9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639209320014944035%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9LN9rlfkn%2BtNjd7vRo1P1gcwvZac780gVBFOjFkDFF4%3D&reserved=0<https://www.ietf.org/archive/id/draft-ietf-dmm-tn-aware-mobility-29.txt> Diff: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-dmm-tn-aware-mobility-29&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C5b0ddc0f5eab41ca9e1c08deed7d63e9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639209320015561443%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uT%2B8Q%2B3SU49A9MdvFpZ2Vk4UHWs3bXp4P8aM74CuxLA%3D&reserved=0<https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmm-tn-aware-mobility-29> Best Regards, John From: Mohamed Boucadair via Datatracker <[email protected]<mailto:[email protected]>> Sent: Thursday, 02 July 2026 10:02:10 To: The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Mohamed Boucadair's Discuss on draft-ietf-dmm-tn-aware-mobility-26: (with DISCUSS and COMMENT) Mohamed Boucadair has entered the following ballot position for draft-ietf-dmm-tn-aware-mobility-26: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-tn-aware-mobility/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Uma, John, Sridhar, Jeff, and Luis, Thank you for the effort put into this specification. Please find below some pints for DISCUSSion: # Mobility-awareness & Key technical contribution CURRENT: 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". The reasoning above applies for all schemes that map S-NSSAIs to transport identifiers, such as already those described in RFC 9889. I'm concerned that the document may be interpreted as if the IETF is recommending this approach compared to other approaches. It would be weird to make such recommendation anyway because that is up to operators to decide the approach that fits their needs and aligned with the capabilities they deploy. So, instead of tagging this option as the only one which is "mobility aware", I suggest to position this work as a realization model based on tunnel transport source port/ranges. That is, this is an applicability of the RFC9834 extension defined in I-D.ietf-dmm-udp-tunnel-acaas-extn (3.3 is the main contribution here). I suggest that the title is also updated accordingly. This approach is consistent with Section 6.5 of draft-ietf-teas-5g-network-slice-application The details of this solution is described in [I-D.ietf-dmm-tn-aware-mobility]. # Normative references At least [RFC9543], [I-D.ietf-dmm-udp-tunnel-acaas-extn], [RFC9834], [RFC9889], and NRM should be normative. Please check the classification of other references and fix as appropriate. Thanks. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # For Chairs/AD: As this is a document covering an architecture owned by another SDO, I wonder whether there was an LS sent to the 3GPP about this doc? # Leverage Existing RFCs & Consistency RFC9889 already clarifies the concept of slicing in 3GPP, the concept of TN, relationship between TN slicing and IETF Network Slicing, mapping considerations, realization of TN slicing beyond identification matters, various deployment options for the location of SDP, the attachment circuits, etc. I suggest that this draft builds on RFC9889 rather than repeating some matters. For example, Sections 2 and 4 can be removed, IMO. rfc9889#section-3 has already all these details. Moreover, the document should be updated to use a terminology that is consistent with existing RFCs. For example, "end-to-end 5G slice" should be "5G end-to-end slice", etc. Cheers, Med
_______________________________________________ dmm mailing list -- [email protected] To unsubscribe send an email to [email protected]
