# [DMM Working Group][1] - IETF 115 {#dmm-working-group---ietf-115} **Tuesday, 8 November 2022, 09:30-11:30 (UTC)** Chairs: Sri Gundavelli, Dapeng Liu, Satoru Matsushima Minute taker: John Kaippallimalil Login to the IETF datatracker to access: * **Meetecho: https://meetings.conf.meetecho.com/ietf115/?group=dmm&short=dmm&item=1** * **Note: https://notes.ietf.org/notes-ietf-115-dmm** * **Zulip: https://zulip.ietf.org/#narrow/stream/dmm** ## Agenda {#agenda} * Administrivia & Intro, WG organization & milestones, Chairs, 5 min. * ### Working Group Drafts {#working-group-drafts} * AD Review update for draft-ietf-dmm-srv6-mobile-uplane, Erik/Sri, 5min. * 3GPP input from Lionel (CT4 chair) * Authors are ok to comply with 3GPP and be consistent * Suresh clarifies that the architecture may propose improvements but will not change 3GPP * Hannu asks for last call clarification on the draft * Mobility aware Transport Network Slicing for 5G, [draft-ietf-dmm-tn-aware-mobility][2], John Kaippallimalil, 15 min. how does the 3GPP network relate the 3GPP configuration (GTP-U) to IP for slices (Tianji) Hannu clarifies that this is an active discussion in TEAS Requests for working group and chair reviews of draft ### Individual Drafts {#individual-drafts} * Mobile User Plane Evolution, Zhaofui Zhang, 15min. [draft-zzhang-dmm-mup-evolution][3] distributed UPF and gNB as motivation. Software may run separate these functions what if we combine in 6G? This is identified in the draft as ANUP The rest is routing switching DU, CU, UPF may be in the same data center Sri asks how does mobility work? Response that there is no change to it Hannu asks what changes if we integrate these functions now? Response that signaling changes (in later slide) Suresh asks similar question as Hannu: and adds handover from 1 gNB to another where the IP address can change Multiple RRU/DU will send to a more central CU. This should be stated as an assumption Suresh asks about TEID and QoS. Author responds that it needs to be addressed John asks about QoS model which is one constraint and this does not address it Author will follow up off line Periodic refresh of N3 tunneling and signaling is a cost (GTP-U) NAT and overlapping private address space, gateways does not change handling ULCL/I-UPF for MEC- where filter intercepts some flows. Avoided by distributed UPF, and ANUP does not change this. Does the AN have to do more work?: the total amount of work is not increased. Author responds that for capacity planning, it may be easier. Does AN complexity increase? The CU already handles significant work and resolution of some IP aspects can be reduced. Is this against micro service architecture? However, this is about integrating forwarding functions and is not about micro-services. Hannu asks how multi access is supported? Author responds and will follow up offline Marco likes draft but notes that it is 3GPP specific. What kind of changes like traffic steering, etc. are needed in IETF? Author responds that no changes are needed in IETF. The aim is to get support and feedback from operators and others. Satoru asks about fundamental architecture followed by 3GPP groups Author agrees that it is a big change Lionel comments that 3GPP will consider this as a deployment option, the details will be a deployment option. IETF should look for IP/user plane optimization (similar comment as Marco) Lionel notes that if all the functions are in a box, it does not need further standards. Author responds that N3 signaling is avoided, but Lionel clarifies that implementations can follow anything if 3GPP interfaces are not affected (i.e., they are internal implementations inside the box) Tianji suggest to bring this to 3GPP Suresh request to consider all the comments that there are several implementations where they combine functions The question is how to address cases when the functions are not colocated Author clarifies that there are simplifications in functions, interfaces and will socialize with 3GPP next week. Sri requests that IETF aspects need to be identified and then it will be relevant to this group. * SRv6 Mobile User Plane Architecture, Satoru Matsushima, 15min. [draft-mhkk-dmm-srv6mup-architecture][4] Presents updates for this draft. Explains collapsed SRv6 MUP PE which is a new model in this version. Eric asks if there will be questions about 3GPP architecture and how to address? Sri clarifies that it is an individual draft at this point. Sri asks Eric if IETF can make recommendations as in the same manner as IPv6 recommendations were made (if there is consensus)? Eric clarifies that if it is informational and one way to do it, then maybe. Satoru notes that if the operator wants to use an architecture like this, the draft provides some guidance. There is no impact to 3GPP architecture. Suresh says that there may be an impact to 3GPP architecture. i.e., for fixed wireless there is a simpler approach with BE traffic and no accounting, this may be an approach. Whether this impinges arch or not should be discussed here. Maybe explore in parallel if 3GPP study or use cases is considered in stage 1 Tianji notes that there may be some impact to 3GPP architecture, i.e., 3GPP 5G system may need to get some information/expose to 3rd party may need changes. It is not one way but a two way signaling impact between user plane (in this draft) and 3GPP CP. Author responds that whether the interfaces are exposed are up to the implementation. Any mobility management system 4G, 5G can use this. * Cryptographically Generated Device identifiers, Sri Gundavelli, 15min. [draft-gundavelli-dmm-device-identifier][5] how can multiple devices use the same identity semantics for device identification solution with cryptographically generated device identifiers Lionel asks if using device identifier that is encrypted, how it will be used Sri answers that key pairs are used and so the network can validate. Tianji asks about SUPI allocated by the operator Sri notes that SUPI is on the 5G side, but there is question of WiFi, i.e., it should be at a layer above Lionel notes that it will be IMEI and there is a solution to encrypt * Media Header Extensions for Wireless Networks, John Kaippallimalil, 15min. [draft-kaippallimalil-tsvwg-media-hdr-wireless][6] motivation is to provide metadata for media packets to the wireless to compensate for rapid changes in link capacity this requires the application to provide some metadata - priority, time budget and burst length and a means to transport from application to wireless network. Hang Shi notes that these methods should apply to the wireline access also. Sri concurs and notes that cable access has similar fluctuation in capacity as wireless networks. Lorenzo comments that application runs their own optimizations and the metadata/wireless optimization may interfere John responds that the process should be with Application control and in a cooperative manner, more work needs to be done for managing trust and handling the multiple control input/feedback. Tianji asks how the information provided in N6/IP transport is conveyed in 3GPP to the radio. John responds that 3GPP has studied the segment /how to convey information to radio over N3. However, the question is how encrypted media like HTTP/3 can provide the metadata to the wireless network. * Transporting IP/UDP Payload-only in VPNs, Zhaofui Zhang, 15min. [draft-zzhang-bess-ipvpn-payload-only][7] use case mobile user plane transportation SRv6 transport replacing GTP For MPLS, SRv6 header could use an MPLS label. GTP header is retained. Tianji comments about how the information in GTP header. In MPLS, GTP header is kept and in SRv6 most of the parameters are mapped. Tim Costello, BT asks if there are liaison statements exchanged with 3GPP? Author clarifies that there are no changes in 3GPP and hence not sent. ### AOB {#aob} [1]: https://tools.ietf.org/wg/dmm [2]: https://datatracker.ietf.org/doc/draft-ietf-dmm-tn-aware-mobility [3]: https://datatracker.ietf.org/doc/draft-zzhang-dmm-mup-evolution/ [4]: https://datatracker.ietf.org/doc/draft-mhkk-dmm-srv6mup-architecture [5]: https://datatracker.ietf.org/doc/draft-gundavelli-dmm-device-identifier [6]: https://datatracker.ietf.org/doc/draft-kaippallimalil-tsvwg-media-hdr-wireless/ [7]: https://datatracker.ietf.org/doc/draft-zzhang-bess-ipvpn-payload-only