Hi Miya, Please see zzh2> below.
From: Miya Kohno <[email protected]> Sent: Tuesday, May 18, 2021 10:31 AM To: Jeffrey (Zhaohui) Zhang <[email protected]> Cc: Joel M. Halpern <[email protected]>; [email protected] Subject: Re: [DMM] Architecture Discussion on SRv6 Mobile User plane [External Email. Be cautious of content] Thank you, Jeffery. All are great points. Please see inline [MK]. On Mon, May 17, 2021 at 11:22 PM Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>> wrote: Hi Miya, Please see zzh> below. From: Miya Kohno <[email protected]<mailto:[email protected]>> Sent: Friday, May 14, 2021 11:04 PM To: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>> Cc: Joel M. Halpern <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [DMM] Architecture Discussion on SRv6 Mobile User plane [External Email. Be cautious of content] Hi Jeffrey, Thank you very much for your review and comments. The two points you picked up are somewhat important, but what's more important is that if we are tied to the GTP-U, we cannot break-through the current tunnel-session convention, where: - tunnel-session gateways become a scaling bottleneck. - it is not optimal for distributed data and applications. Zzh> Not exactly clear what “gateways” you’re referring to, but I have the following thoughts on the tunnel-session convention. Zzh> Consider the typical wireline/IETF VPN scenario: CE1001 ---- PE1 ------- P -------- PE2 ---- CE2000 … / CE1999 –-/ Zzh> PE1 has 1000 CEs connected in a VRF, say via VLANs. IP adjacencies from the CEs terminate on PEs, therefore PE1 only need to advertise one label/SID for the VRF. Traffic from CE2000 to any of the CEs off PE1 will have an IP lookup in PE2’S VRF first, and a tunnel with that single label/SID is used to reach PE1, who will do an IP lookup in the VRF to determine where to send the traffic. Zzh> Now consider 5G: UE1001 ---- gNB1 –----- P -------- UPF1 ---- DN … / UE1999 –-/ Zzh> gNBs are not IP terminating points (wrt PDU sessions from UEs). UPFs terminate the PDU sessions and they need tunnels to the UEs for those PDU sessions. As long as UPFs need to distinguish which UE the traffic is to/from, it does not matter whether the PDU sessions are instantiated via GTP-U or SRv6 (and if some UEs do not need to be distinguished for uplink traffic, then the same TEID can be used with GTP-U as well, similar to wireline/IETF VPN case or as mentioned in draft-ietf-dmm-srv6-mobile-uplane section 5.2.3). In other words, 3GPP would need to decide if the tunnel-session convention will continue and before that changes, the two points you mention won’t be changed by SRv6. [MK] ----------------- In case of the 5G diagram, UPF1 is the tunnel session termination point. It's more vulnerable for its overload or failure. In the case of the IP VPN diagram, multiple PEs along with PE2 can form a multi-homing / load-balancing cluster. I agree with you that If the control plane does not change, the benefits of statelessness cannot be fully realized. However, as long as we are stuck with the tunnel-session convention, we can't even think about the benefits of statelessness. Zzh2> But my understanding is that SRv6 does not change the tunnel-session convention. So if we want to make real impact, it would be to turn the gNBs into a PE role and have the PDU session terminating on that. I doubt we’ll ever be able to achieve that. gNB will always be there even when UPFs are distributed (and hosted on the same device as the gNBs) – gNBs are like the ethernet switches in our wireline networks and the tunnels are like VLANs. ----------------- Zzh> UPFs can be distributed, e.g. to gNB sites. Even with that, the tunnels still exist unless 3GPP changes the tunnel-session convention (and before then SRv6 won’t help), just that they do not go across a large transport network. However, the distributed UPFs do optimize for distributed data and applications. [MK] ----------------- Indeed, distributed UPFs are good for distributed data and applications. But in that case, it's less optimal for mobility, i.e. tradeoff between session continuity vs traffic optimality. That's why 3GPP additionally defined "SSC mode2", which allows the session re-establishment and IP address change when UE moves. However, should it be 3GPP who decides if applications (or the L4 path such as MP-TCP, MP-QUIC, etc.) require the IP address persistence or not? Zzh2> The real question is not who decides if persistence is required or not, but if 3GPP procedures can support persistence addresses or not, when UEs change their anchor UPFs. This is a sidetrack from this email thread (not relevant to the “SRv6 mobile user plane” topic) but I happen to have some experience on this so let me share here. Zzh2> As part of the 3GPP Rel 17 Study Item for Edge Computing, one question is how to support computing service continuity when the UE address changes. I had a proposal to provide persistent addresses even when a UE moves to a different anchoring UPF. It was accepted in the study phase, but when it went to the phase to conclude the study and determine what goes into actual work phase I was overwhelmed with other priorities and did not get to answer some questions so it did not go into the work phase. I don’t know if I’ll be able to get it into Rel 18 but I do believe it is a problem with a feasible solution. I can provide more details separately if you’re interested. Also, in the first place, GTP-U tunnels will still be required if IP address persistence will no longer be required? Zzh2> My understanding is that GTP-U is not used only for tunneling to central UPFs who could provide persistent addresses. It is like a VLAN in wireline networks – a lower layer below the PDU session. Whether central UPFs are used or not, whether persistent addresses are used or not, I don’t think the tunnel-session convention is going away in 5G or 5G-Advanced. When the system architecture needs to evolve, I think the architectural domain silo and the boundary should be re-visited. Zzh2> Breaking the silos is definitely a good thing, but since 3GPP is the owner of mobile specifications, we can’t standardize specifications in IETF for mobile networks. We can try to influence their design choices by talking to 3GPP folks in their forums (it seems that for some vendors/operators even their internal conversation between wireline and wireless folks are not much), but they make decisions. Zzh2> Jeffrey ----------------- We will improve the section 2 "problem statement" to be clearer. Zzh> Will see how it turn out. I do not agree with current statements in the section – at least GTP-U transport over SRv6 should work well for non-MPLS operators. I never think MPLS is dead. But I don't think that's a reason to discourage new options. As access technologies become more diverse and computing is more distributed, the importance of FMC (Fixed Mobile Convergence) increases more than ever. Currently, FMC is discussed exclusively in 3GPP/BBF, but I hope that the IETF community, knowing the strength of IP as a stateless common data plane, will influence the industry a bit more. Zzh> My point is that, if you are a 3GPP person, would you specify two ways for PDU sessions? The SRv6 way won’t work for MPLS operators, while the GTP-U way should work well for any operators. Zzh> Clean layering has its architecture advantages. Even if an operator does not like many layers of IPv6/UDP/GTP headers, the drop-in mode in draft-ietf-dmm-srv6-mobile-uplane can address that transparently. Zzh> Again, the arguments need to be made in 3GPP, not in IETF. [MK] ----------------- It would not be good to make the SDO silo decisive, when an architectural evolution is needed, would it? (BTW, the SRv6 way does not necessarily mean it won't work for MPLS. Though this topic is out of the scope of this draft.) ----------------- Zzh> Thanks. Zzh> Jeffrey Thanks, Miya On Tue, May 11, 2021 at 3:57 AM Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>> wrote: Hi Miya, As Joel pointed out, it is 3GPP not IETF who may adopt SRv6 as a user plane. Before then, we have to take GTP-U as granted. Of course, if IETF can reach consensus on the merit, we could recommend to 3GPP and they can decide whether to take it or not. The draft talks about various advantages in various use cases, but I don't see why 3GPP needs to move away from GTP-U. If I understand it correctly, the draft mainly talks about two reasons: 1. 5G NF nodes (as GTP-U tunnel endpoints) are better off not being CEs off PEs 2. SRv6's TE and program capability solve lots of problems However, it does not explain why it would not work if an NF node continues to use GTP-U but put it on top of SRv6 (w/o PE/CE separation). The way I (and perhaps some 3GPP folks) see it, a 5G NF may be better off not being concerned with how a GTP-U packet is steered across the network (e.g. figuring out and encoding the SRH) but leaving it to the network layer. Note that this does not mean the NF has to be a host/CE separate from a PE. It could be that the 5G NF is the application layer (using GTP-U) on top of the network layer that uses SRv6. In fact, the last paragraph of this document says "it is totally fine to keep ovelray underlay-agnostic": Note that the interaction with underlay infrastructure is not a mandatory in the data plane commonality. It just gives a design option to interact with the underlay and optimize it, and it is totally fine to keep ovelray underlay-agnostic. Additionally, for the drop-in mode described in section 5.4 of draft-ietf-dmm-srv6-mobile-uplane, the two SRGWs can be implemented either as standalone entities or as part of the network stack on the 5G NFs themselves. This achieves the same result as if 3GPP replaced GTP-U with SRv6 w/o any impact to existing 3GPP specifications or implementations. So, what really matters is why the GTP-U encapsulation should be integrated/dissolved into SRv6 header itself, and make sure that the 3GPP (not IETF) folks are convinced of that. Related to convincing 3GPP folks of the above, one question is - is MPLS dead already? Are there operators not using SRv6 transport? As long as there are still operators not using SRv6 for transportation, why would 3GPP want to have two ways, when the existing GTP-U works for both? Thanks. Jeffrey -----Original Message----- From: dmm <[email protected]<mailto:[email protected]>> On Behalf Of Joel M. Halpern Sent: Friday, May 7, 2021 10:41 AM To: Miya Kohno <[email protected]<mailto:[email protected]>>; dmm <[email protected]<mailto:[email protected]>> Subject: Re: [DMM] Architecture Discussion on SRv6 Mobile User plane [External Email. Be cautious of content] Without getting into the content, when it comes to whether GTP-U is the mechanism for carrying cellular mobile user data, that is a 3GPP decision, not an IETF decision. Yours, Joel On 5/7/2021 10:35 AM, Miya Kohno wrote: > Dear DMM WG, > > Following up the discussion at the IETF110 > (https://urldefense.com/v3/__https://codimd.ietf.org/notes-ietf-110-dmm__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBr19WLV0$<https://urldefense.com/v3/__https:/codimd.ietf.org/notes-ietf-110-dmm__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBr19WLV0$> > <https://urldefense.com/v3/__https://codimd.ietf.org/notes-ietf-110-dmm__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBr19WLV0$<https://urldefense.com/v3/__https:/codimd.ietf.org/notes-ietf-110-dmm__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBr19WLV0$> > >), I would like to have your > review on the draft - > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-kohno-dmm-srv6mob-arch-04__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBnDKFo0K$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-kohno-dmm-srv6mob-arch-04__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBnDKFo0K$> > <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-kohno-dmm-srv6mob-arch-04__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBnDKFo0K$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-kohno-dmm-srv6mob-arch-04__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBnDKFo0K$> > >. > > The purpose of this draft is to support the value of the SRv6 mobile > user plane > (https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-12__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBsfnapQb$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-12__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBsfnapQb$> > <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-12__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBsfnapQb$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-12__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBsfnapQb$> > >), > and to be a trigger to revisit the current situation where GTP-U is > taken for granted as a mobile user plane. > > > Thanks, > Miya - on behalf of the authors > > _______________________________________________ > dmm mailing list > [email protected]<mailto:[email protected]> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBluay8Xc$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBluay8Xc$> > _______________________________________________ dmm mailing list [email protected]<mailto:[email protected]> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBluay8Xc$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBluay8Xc$> Juniper Business Use Only Juniper Business Use Only Juniper Business Use Only
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
