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
<[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
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
