[DMM] Mohamed Boucadair's Discuss on draft-ietf-dmm-tn-aware-mobility-26: (with DISCUSS and COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

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