Ballot for draft-ietf-dmm-tn-aware-mobility
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
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.
# 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
Thank you for writing this document. I note that "IP transport" in this context means transport of IP over UDP over IP, although I see only one transport-related concern;-): ## The way in which the UDP source port number is used appears to prevent the use of source port randomisation, a useful technique to mitigate vulnerability to off-path attack. This is expected to be acceptable use. The concern maybe was intended to be included within "To avoid spoofing..", although I'd encourage this to be explicitly stated to note this as a security consideration (perhaps cross-referencing Sect 5.1.1. of 5.1.1) and to link this to mitigations to such attack, where I see IPsec and ACLs suggested as viable possible approaches. ## I do wonder if RFC 9543 is normative background (f not, what provides the normative basis for the technologies?).