I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-dmm-srv6-mobile-uplane-?? Reviewer: Gyan Mishra Review Date: 2022-12-03 IETF LC End Date: 2022-11-23 IESG Telechat date: Not scheduled for a telechat Summary: This document specifies the applicability of SRv6 (Segment Routing IPv6) to the user-plane of mobile networks. The network programming nature of SRv6 accomplishes mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying transport can be beneficial to the mobile user-plane, providing flexibility, end-to-end network slicing, and SLA control for various applications. This draft is well written and is almost ready for publication with a few minor nits and issues I would like to have addressed. I have been following this draft throughout its progression and I believe it’s a very critical and important optimization for operators to be able to leverage SRv6 in the 5G Cloud RAN virtualized environment. Major issues: None Minor issues: I noticed that this draft does not mention the use of SRv6 CID endpoint flavor uSID or GSID. All implementations that would be deployed now would either use one of the two endpoint flavors either uSID 16 bit uSID which can support up to 5 or 6 uSID within a uSID carrier using shift and forward Next endpoint behavior and G-SID can support up to 3 32 bit G-SID within a single carrier using Replace endpoint behavior which requires copy of G-SID from SRH to DA. So I think it’s important to mention that MUP is relevant for maybe Full SID and CID Next and Replace endpoint functions or as any future deployment would not use the Base Full 128 bit SID I think it’s fair to say that MUP is applicable to the SRv6 compression CSID endpoint behaviors Next and Replace SID. Since section 5.4 SRv6 drop in interworking is the section that defines the MUP specification for standardization my recommendation is to maybe make a separate section would make it more clear and then would avoid having to state in the introduction that all section 5 sub sections are informational and only 5.4 is standards track. Also in creating a new section I would put that before the information section. Also for the informational sections heading “5G MUP operational models suggestions”. Another idea is to remove the informational sections from the body and move to appendix. For the reader as it’s all clumped together in the body, for the reader it does make it confusing as to why some or all of that is not part of the MUP specification and raises questions as to why it should or should not be informational. The operational models include traditional and enhanced replaces the GTP-U to use existing SRv6-VPN PGM endpoint functions and traditional no SRv6 TE way points where enhanced mode includes SRv6 TE way points and two interworking cases with legacy gNB GTP-U for IPv4 and IPv6. The two modes and interworking modes use existing SRv6 endpoint behaviors so is not introducing anything new thus the reason for keeping as informational models and I agree. However breaking up the Standard and informational sub sections into separate sections would help the readability of the specification. Nits/editorial comments: GTP and GTP-U are mentioned throughout the draft and both AFAIK refer to the UE Generic Tunneling Protocol User Plane encapsulation. I would use GTP-U throughout the draft. On page 6 5G terminology section please mention GTP-U as well maybe mention what each Nx interface represents. Under terminology you mention VNF and CNF. So my understanding is both VNF and CNF are components of NFV MANO and programmatically chaining VNF / CNF together into a service chain. VNF refers to use of VM virtual machines guest OS sitting on a hypervisor and separate binaries where CNF refers to a container sitting on the host OS with shared binaries with context name spaces that logically separate the container providing the network functions. So the natural progression has been from PNF physical hardware to VNF - VMs to now CNF - cloud native containers. AFAIK I don’t think this description is correct VNF: Virtual Network Function (including CNFs) Page 5 section 3 Old It is also suitable for virtualized environments, like VNF/CNF to VNF/CNF networking. New It is also suitable for virtualized environments, like VNF/CNF to VNF/CNF networking. Section 2.3 mentions endpoint behavior AFAIK that are applicable to the informational operational models. Maybe should mention that explicitly and as not all endpoint behaviors are mentioned that is my interpretation of the section. So if that is the case End.DX2 I don’t think EVPN would be relevant and only L3 VPN endpoint behaviors would be relevant. Section 3 3rd paragraph In the meantime, applications have shifted to use IPv6, and network operators have started adopting IPv6 as their IP transport. SRv6, the IPv6 dataplane instantiation of Segment Routing [RFC8402], integrates both the application data-path and the underlying transport layer into a single protocol, allowing operators to optimize the network in a simplified manner and removing forwarding state from the network. In this paragraph are we referring to SRv6 in particular that the VPN service layer FUNCT encoding and transport layer Locator encoding into the SRv6 SID merging together into a flat data plane with SRv6 BGP Overlay RFC 9252 as compare to traditional SR-MPLS 2 level label stack. This flat data plane also caters to cloud native networking and 5G Cloud RAN virtualization of networking components. In Section 3 motivation maybe mention the 5G architectural change to virtualized Cloud RAN - NFV / CNF cloud native - that makes the change to SRv6 much more prudent for operators as SRv6 uses the native IPv6 data plane as compare to SR-MPLS which reuses the MPLS data plane.