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

[Miya Kohno <[e-mail]>]

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 <
[e-mail]> wrote:

> 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 <[e-mail]> *On Behalf Of * Miya Kohno
> *Sent:* Friday, May 7, 2021 9:35 AM
> *To:* dmm <[e-mail]>
> *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,
>
> Miya - on behalf of the authors
>