DMM sessions

1. chairs went to agenda 1st

2. WG draft: Mobility aware Transport Network Slicing for 5G

   • in good shape now; request for WG LC;
   • talked about a bunch of changes
   • major change: from 'EP_Transport in 3gpp term' to ACaaS in IETF
     GTP term
   • reviewed some changes in TEAS work (especially in slicing)
   • emphaszied nothing changed on 3GPP-related slicing architecture
   • went thru 3GPP TS 28.541 (reference to EP_Transport)
   • added ACaaS extension for GTP (l3-service) in YANG model
   • Q&A: on the slide#6: slice-mapaping UDP src-port# with ACaaS:
     NSSAI vs. S-NSSAI
   • Chair: origianlly only expected to see impact on PE router, but
     the range of the model extended to gNB

3. ANUP

   • the comments on 'consensus' has been addressed -- it is fine to
     not have an implemenation as long as it is not implementable.
   • L.Morand: better lay out how the CP will be impacted (e.g.,
     SMF/AMF, PDU-session setup, UE handover across gNB) with the
     intergrated ANUP. E.g., with ANUP, what will be procedure like
     for session setup?
   • WG chair: 2 parts in the draft: while the 1st-part lays the
     foundation for the 2nd-part, believe the 1st-part is sort of
     biased in term of analysis to support the 2nd-part. So,
     suggestion is to revise the 1st-part; may be simplified it.
   • FW: maybe make it more generalized...

4. MUP Architecture for DMM

   • talked about MUP architecture with 3GPP 5G over SRv6
     implementation
   • Recap of architecture principles (3)
   • Reminder: DMM Requirements (RFC7333)
   • Compared with RFC-9433, this I.D. claims a pluggable Uplane
     architecture for any mobile service system (while RFC-9433 is
     more toward DP protocol option in SRv6 case)
   • E.Kline(AD): Does this intend STD track?/is informational ok? ->
     yes/if it is the case.
   • L.Morand: seems nothing to be standardized; so, is it better to
     be for informational track? -> this I-D is the base architecture
     to define STD protocols. Hence in STD track.
   • there is one related BGP draft in BGP-BESS
   • WG chairs have requested the team to review, provide comments
     before proceed with adoption call.

5. Mobile Traffic Steering

   • talked about the background & past activites (since IETF-116);
     basic scenarios, past discussions
   • up-to-date progresses on the I.D.: use cases, deployment
     options, reference points & information model
   • Draft structure is shown
   • Q1: relation with CATS? want to keep orthogonal from CATS; this
     draft is more general, not restricted to any specific mobile
     system.
   • Q2: is the traffic steering per-flow/per-session (since the I.D.
     talks about 3GPP architecture)?
   • Q3: relationship to N6-intf 'router' on traffic steering: how
     the N6-intf 'router' may interact with the transport-domain
     network?

6. Computing Aware Traffic Steering Consideration for Mobile User
   Plane Architecture

   • went thru updates: centralized CATS-MUP vs. distributed CATS-MUP
   • Q1: how to handle the stateful-service based on the CATS? i.e.,
     always stick to the same service instance.
   • Q2: CATS related metrics are not yet stable; concerns are they
     might lead to routing instability. Thus, suggestion is to talk
     to BGP team.

7. Computing Aware Traffic Steering using IP address anchoring

   • Enhance the MUP architecture with Computing-Aware Traffic
     Steering (CATS) concept from CATS WG.
   • Claim to be a potential approach for CATS supporting mobility;
     looking for feedback from both CATS and DMM WGs.
   • Q1: how to handle stateful-service with the I.D. propsoal? e.g.,
     how to maintain the 'sticky' service-instance?
   • Q2: to clarify 'service continuity with UE mirgration and/or
     potential AS changes.
   • Q3: a 5G standardized scenario on leveraging N6 delay to EAS'es
     for the slection/reslection of UPFs and/or EAS'es. (so far, only
     delay-parameter is standardized, while 'computing'-parameter
     would be considered later.)

8. SRH Reduction for SRv6 End.M.GTP6.E Behavior

   • Q1: clarification on whether the SR-endpoint behavior codepoint
     has been allocated -> not yet.
   • DMM chairs: let's continue discussion on alias; but an
     informational draft should be better.

9. Introducing the 6G reset initiative

   • talked about the general view of 6G
   • claimed 6G should not be just 3GPP; it should include more
     technologies, e.g., wifi, fixed wireless, etc.