Re: [DMM] Architecture Discussion on SRv6 Mobile User plane

But isn't that a debate for 3GPP to have?  It is their architecture.
I am very glad the IETF reacted when ITU-T tried to change important 
parts of our architectures.  But the corollary is that we should respect 
other people's architecture.  if we want to change it, we should go 
there and debate it with the owners.

Yours,
Joel

PS: The fact that 3GPP rejected the last effort by Cisco to convince 
them to make the change (3GPP has corporate members) does not mean that 
people should venue shop for alternatives.  If you think things have 
changed, go back and remake the case there.  (Personally, I don't think 
they have changed that much.  But it is not my call.  It is 3GPP's.)

On 5/14/2021 11:03 PM, Miya Kohno wrote:
> 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.
> 
> We will improve the section 2 "problem statement" to be clearer.
> 
> 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.
> 
> Thanks,
> Miya
> 
> On Tue, May 11, 2021 at 3:57 AM Jeffrey (Zhaohui) Zhang 
> <zzhang@juniper.net <mailto:zzhang@juniper.net>> 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 <dmm-bounces@ietf.org <mailto:dmm-bounces@ietf.org>> On
>     Behalf Of Joel M. Halpern
>     Sent: Friday, May 7, 2021 10:41 AM
>     To: Miya Kohno <miya.kohno@gmail.com <mailto:miya.kohno@gmail.com>>;
>     dmm <dmm@ietf.org <mailto:dmm@ietf.org>>
>     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
>      > dmm@ietf.org <mailto:dmm@ietf.org>
>      >
>     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
>     dmm@ietf.org <mailto:dmm@ietf.org>
>     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
> 