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

From: Miya Kohno <[email-masked]>
Date: Fri, 7 May 2021 23:35:20 +0900

Dear DMM WG,

Following up the discussion at the IETF110 (
https://codimd.ietf.org/notes-ietf-110-dmm), I would like to have your
review on the draft -
https://tools.ietf.org/html/draft-kohno-dmm-srv6mob-arch-04.

The purpose of this draft is to support the value of the SRv6 mobile user
plane (https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-12),
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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 7 May 2021 10:41:04 -0400

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://codimd.ietf.org/notes-ietf-110-dmm 
> <https://codimd.ietf.org/notes-ietf-110-dmm>), I would like to have your 
> review on the draft - 
> https://tools.ietf.org/html/draft-kohno-dmm-srv6mob-arch-04 
> <https://tools.ietf.org/html/draft-kohno-dmm-srv6mob-arch-04>.
> 
> The purpose of this draft is to support the value of the SRv6 mobile 
> user plane 
> (https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-12 
> <https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-12>), 
> and to be a trigger to revisit the current situation where GTP-U is 
> taken for granted as a mobile user plane.
> 
> 
> Thanks,
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 10 May 2021 18:57:48 +0000

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-masked]> On Behalf Of Joel M. Halpern
Sent: Friday, May 7, 2021 10:41 AM
To: Miya Kohno <[email-masked]>; dmm <[email-masked]>
Subject: Re: [DMM] Architecture Discussion on SRv6 Mobile User plane

[External Email. Be cautious of content]

Yours,
Joel

On 5/7/2021 10:35 AM, Miya Kohno wrote:
> (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-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://www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBluay8Xc$
>

_______________________________________________
dmm mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBluay8Xc$

Juniper Business Use Only

---

From: Kaippallimalil John <[email-masked]>
Date: Mon, 10 May 2021 18:58:33 +0000

Hi Miya, DMMers,
Here are my comments on this draft.

General:
This draft has considered some well understood problems with tunnels - in this case GTP - and proposed SRv6 to address it.
The draft does outline various scenarios (edge computing, URLLC, etc) where SRv6 is perceived to be beneficial, but these assertions are not backed up with enough details.

  1.  Perhaps Annexes with details and comparison to GTP can help readers follow these better.

  2.  Many of the advantages (e.g., in section 5) seem much more than just replacement of GTP with SRv6 (other control plane entities like SMF, PCF seem to be affected)
Section 6 on CP considerations - is IGP or BGP going to replace part of the 3GPP CP ?

  3.  Since this draft is about advocating the use of SRv6 in mobile network/5G architecture, some questions remain unanswered:
(Note: the comments are wrt SRv6 used to replace GTP. SRv6 used to transport GTP is not covered by the draft, and not intended in any of the comments)

  *   is this architecture a replacement for a part of 3GPP, and if so how does it integrate with the rest of the 3GPP architecture (both RAN and core)
  *   how would legacy GTP based architecture interwork with this SRv6 arch. Even 5G networks may be non-standalone - apart from interworking with previous generations.
  Wouldn't a mixed GTP + SRv6 architecture increase the complexity of any deployment?
  *   since 3GPP is continuing to work with GTP, all enhancements in upcoming releases will also be made to GTP. How would this SRv6 architecture deal with this?
In other words, if SRv6 were to be an alternative (not defined by 3GPP), it is not clear in the draft how that could be practically used.

Specific comments:

  1.  the Abstract talks about general benefits of common SRv6 overlay/underlay but does not say anything about the key aspect: i.e., SRv6 in mobile networks - 3GPP/5G.

2.  section 1 ,Introduction: "GTP-U will not be able to meet the diverse SLA requirements ..."
Many similar assertions, but not backed up with details to let the reader understand why that is the case.

  1.  Section 1, Introduction: what is a "mobile-first data intensive application" and why would that be more dynamically distributed.
If this is of significance to GTP/SRv6 it should be explained.
  2.  Section 3:  "Since SRv6 is a native IPv6 data plane, it can be a common data plane regardless of the domain"
Perhaps not intended, but it looks like SRv6 may replace radio transport (PDCP) as well.  Also related to comment (A).
  3.  Section 5.2: For many of these advantages, it seems like much more than SRv6 replacing GTP. Many CP components like SMF, PCF would at the very least be affected.
  4.  Section 6: is IGP or BGP going to replace part of the 3GPP CP?
"slight modification" is vague. Perhaps it would be good to understand what in 3GPP CP would change.
  5.  Section 7: see comment (C) that has a similar consideration as in this section.

BR,
John

From: dmm <[email-masked]> On Behalf Of Miya Kohno
Sent: Friday, May 7, 2021 9:35 AM
To: dmm <[email-masked]>
Subject: [DMM] Architecture Discussion on SRv6 Mobile User plane

Dear DMM WG,

Following up the discussion at the IETF110 (https://codimd.ietf.org/notes-ietf-110-dmm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcodimd.ietf.org%2Fnotes-ietf-110-dmm&data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cac4cb36ead684eec1cb508d911656628%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637559949508585154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HYvLlZ1mlvIIHOXIi6xTBK4fDH2Ues%2Fg2g2MxYclU3w%3D&reserved=0>), I would like to have your review on the draft - https://tools.ietf.org/html/draft-kohno-dmm-srv6mob-arch-04<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-kohno-dmm-srv6mob-arch-04&data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cac4cb36ead684eec1cb508d911656628%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637559949508595100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XHeojJC5TG4DltS1AtPi7Q9Q3cOLbxTaqQXRMj%2BBNkc%3D&reserved=0>.

The purpose of this draft is to support the value of the SRv6 mobile user plane (https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-12<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dmm-srv6-mobile-uplane-12&data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cac4cb36ead684eec1cb508d911656628%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637559949508595100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0cJ35%2FjT3r%2BfVwBoB%2FvC8ojBAkK663ThjseXwTZMkRk%3D&reserved=0>), and to be a trigger to revisit the current situation where GTP-U is taken for granted as a mobile user plane.

Thanks,

---

From: Miya Kohno <[email-masked]>
Date: Sat, 15 May 2021 12:03:48 +0900

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-masked]>
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:
>
> 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.
>
> 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
>
> > (
> 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-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$
> >),

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 May 2021 23:08:40 -0400

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:
> important is that if we are tied to the GTP-U, we cannot break-through 
> the current tunnel-session convention, where:
> I never think MPLS is dead. But I don't think that's a reason to 
> discourage new options.
> 
> On Tue, May 11, 2021 at 3:57 AM Jeffrey (Zhaohui) Zhang 
> <[email-masked] <mailto:[email-masked]>> 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:
> 
>     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.
> 
>     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.
> 
>     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
> 
>     From: dmm <[email-masked] <mailto:[email-masked]>> On
>     Behalf Of Joel M. Halpern
>     To: Miya Kohno <[email-masked] <mailto:[email-masked]>>;
>     dmm <[email-masked] <mailto:[email-masked]>>
>     <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://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-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$>
>      >),
>      > [email-masked] <mailto:[email-masked]>
>      >
>     <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBluay8Xc$>
>      >
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!SzV0kRt5R1BtZ6iXWrwQL2PSnxSFw0e-sTZ2WKE6-yG-eF_Ugx6Nj5tSBluay8Xc$>
>

---

From: Miya Kohno <[email-masked]>
Date: Sat, 15 May 2021 12:26:44 +0900

Hi John,

Many thanks for taking time to review and comment.

The intention of the document is to argue the merits of not being locked
into the existing conventions。

So it is difficult to make a tight comparison between existing practices
and new possibilities.

But your points are noted. Let me think more to improve the document.

Today, please forgive me for just answering the questions that I can answer
right away.

> 2 Many similar assertions, but not backed up with details to let the
reader understand why that is the case.

In the first place, this draft is to back up the assertions. Thus section
2, 3 and 5. Let me think more how to improve

> 3 Section 1, Introduction: what is a “mobile-first data intensive
application” and why would that be more dynamically distributed.

IoT data ingestion, streaming processing, distributed analytic, etc. We
will make this explicit

Overall, we should be clear to position the 3GPP architecture as just a
reference. Not to compare, not to replace.

Thanks,

Miya

On Tue, May 11, 2021 at 3:58 AM Kaippallimalil John <
[email-masked]> wrote:

> *General:*
> This draft has considered some well understood problems with tunnels - in
> this case GTP - and proposed SRv6 to address it.
>
> The draft does outline various scenarios (edge computing, URLLC, etc)
> where SRv6 is perceived to be beneficial, but these assertions are not
> backed up with enough details.
>
>    2. Many of the advantages (e.g., in section 5) seem much more than
>    just replacement of GTP with SRv6 (other control plane entities like SMF,
>    PCF seem to be affected)
>    Section 6 on CP considerations – is IGP or BGP going to replace part
>    of the 3GPP CP ?
>
>    3. Since this draft is about advocating the use of SRv6 in mobile
>    network/5G architecture, some questions remain unanswered:
>    (*Note*: the comments are wrt SRv6 used to replace GTP. SRv6 used to
>    transport GTP is not covered by the draft, and not intended in any of the
>    comments)
>
>
>    - is this architecture a replacement for a part of 3GPP, and if so how
>    does it integrate with the rest of the 3GPP architecture (both RAN and core)
>    - how would legacy GTP based architecture interwork with this SRv6
>    arch. Even 5G networks may be non-standalone - apart from interworking with
>    previous generations.
>    - since 3GPP is continuing to work with GTP, all enhancements in
>    upcoming releases will also be made to GTP. How would this SRv6
>    architecture deal with this?
>    In other words, if SRv6 were to be an alternative (not defined by
>    3GPP), it is not clear in the draft how that could be practically used.
>
>
>
> *Specific comments:*
>
>    1. the Abstract talks about general benefits of common SRv6
>    overlay/underlay but does not say anything about the key aspect: i.e., SRv6
>    in mobile networks - 3GPP/5G.
>
> 2.  section 1 ,Introduction: “GTP-U will not be able to meet the diverse SLA requirements ...”
>    1. Section 1, Introduction: what is a “mobile-first data intensive
>    application” and why would that be more dynamically distributed.
>    2. Section 3:  “Since SRv6 is a native IPv6 data plane, it can be a
>    common data plane regardless of the domain“
>    Perhaps not intended, but it looks like SRv6 may replace radio
>    transport (PDCP) as well.  Also related to comment (A).
>    3. Section 5.2: For many of these advantages, it seems like much more
>    than SRv6 replacing GTP. Many CP components like SMF, PCF would at the very
>    least be affected.
>    “slight modification” is vague. Perhaps it would be good to understand
>    what in 3GPP CP would change.
> *From:* dmm <[email-masked]> *On Behalf Of * Miya Kohno
> *Sent:* Friday, May 7, 2021 9:35 AM
> *To:* dmm <[email-masked]>
> *Subject:* [DMM] Architecture Discussion on SRv6 Mobile User plane
>
>
>
> Dear DMM WG,
>
>
>
> https://codimd.ietf.org/notes-ietf-110-dmm
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcodimd.ietf.org%2Fnotes-ietf-110-dmm&data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cac4cb36ead684eec1cb508d911656628%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637559949508585154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HYvLlZ1mlvIIHOXIi6xTBK4fDH2Ues%2Fg2g2MxYclU3w%3D&reserved=0>),
> I would like to have your review on the draft -
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-kohno-dmm-srv6mob-arch-04&data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cac4cb36ead684eec1cb508d911656628%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637559949508595100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XHeojJC5TG4DltS1AtPi7Q9Q3cOLbxTaqQXRMj%2BBNkc%3D&reserved=0>
> .
>
>
>
> plane (https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-12
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dmm-srv6-mobile-uplane-12&data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cac4cb36ead684eec1cb508d911656628%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637559949508595100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0cJ35%2FjT3r%2BfVwBoB%2FvC8ojBAkK663ThjseXwTZMkRk%3D&reserved=0>),

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 17 May 2021 14:22:25 +0000

Hi Miya,

Please see zzh> below.

From: Miya Kohno <[email-masked]>
Sent: Friday, May 14, 2021 11:04 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [DMM] Architecture Discussion on SRv6 Mobile User plane

Hi Jeffrey,

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.
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.

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.
Zzh> Thanks.
Zzh> Jeffrey

Thanks,
Miya

On Tue, May 11, 2021 at 3:57 AM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Miya,

Thanks.
Jeffrey

-----Original Message-----
From: dmm <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: Friday, May 7, 2021 10:41 AM
To: Miya Kohno <[email-masked]<mailto:[email-masked]>>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] Architecture Discussion on SRv6 Mobile User plane

Yours,
Joel

On 5/7/2021 10:35 AM, Miya Kohno wrote:
> (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$> >.
>
> (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$> >),
> [email-masked]<mailto:[email-masked]>
> 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-masked]<mailto:[email-masked]>
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$>

---

From: Miya Kohno <[email-masked]>
Date: Tue, 18 May 2021 23:31:17 +0900

Thank you, Jeffery. All are great points.

Please see inline [MK].

On Mon, May 17, 2021 at 11:22 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Hi Miya,
>
>
>
> Please see zzh> below.
>
>
>
> *From:* Miya Kohno <[email-masked]>
> *Sent:* Friday, May 14, 2021 11:04 PM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Cc:* Joel M. Halpern <[email-masked]>; [email-masked]
> *Subject:* Re: [DMM] Architecture Discussion on SRv6 Mobile User plane
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey,
>
>
>
> Zzh> Not exactly clear what “gateways” you’re referring to, but I have the
> following thoughts on the tunnel-session convention.
>
> 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:
>
>
>
> 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.
-----------------

> 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?
Also, in the first place, GTP-U tunnels will still be required if IP
address persistence will no longer be required?

When the system architecture needs to evolve,  I think the architectural
domain silo and the boundary should be re-visited.
-----------------

> 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.
>
>
>
> 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.
>

[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-masked]> wrote:
>
> Hi Miya,
>
> <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:/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-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:/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$>
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 18 May 2021 18:20:57 +0000

Hi Miya,

Please see zzh2> below.

Sent: Tuesday, May 18, 2021 10:31 AM

Please see inline [MK].

On Mon, May 17, 2021 at 11:22 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Miya,

Please see zzh> below.

From: Miya Kohno <[email-masked]<mailto:[email-masked]>>
Sent: Friday, May 14, 2021 11:04 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] Architecture Discussion on SRv6 Mobile User plane

Hi Jeffrey,

[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.

-----------------

[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

-----------------

[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

Thanks.
Jeffrey

-----Original Message-----
From: dmm <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: Friday, May 7, 2021 10:41 AM
To: Miya Kohno <[email-masked]<mailto:[email-masked]>>; dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] Architecture Discussion on SRv6 Mobile User plane

Yours,
Joel