Re: 5G Edge -Computing Solution drafts can be used for Dyncast (dynamic anycast) use cases

Linda,

At the 5G MEC solution and network i am actively working with, there is no
anticipation of supporting IPv4.  I suggest you adopt this constraint of
only supporting IPv6 as well.

If edge is many locations (1,000s, 10,000s, ...) and 5G is many users and
devices (millions, billions), IPv4 is simply not fit for purpose.  MEC
assumes local break out, so this highly distributed nature also makes IPv4
unworkable.   It would be good to set these expectations early and often to
avoid problematic architectural choices.

CB

On Wed, Nov 4, 2020 at 9:20 AM Linda Dunbar <linda.dunbar@futurewei.com>
wrote:

> Yi Zhou, Liang, Peng, and Peter,
>
>
>
> We have 4 IETF drafts describing the different aspect of the solutions to
> 5G Edge computing, which can cover your use cases and requirement described
> in draft-geng-rtgwg-cfn-dyncast-ps-usecase:
>
>
>
> Through working on the 3GPP Release 17’s 5G Edge Computing project (3GPP
> TR23.748), we noticed that IP Layer can do more to optimize the 5G Edge
> computing services.
>
>
>
> *https://datatracker.ietf.org/doc/draft-dunbar-ippm-5g-edge-compute-ip-layer-metrics/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1yyVDIoM4pRjqoaLcFtGBohA3Our0GjTsZTI_OhhRqrwPug8uB8BZCGk2WVCYZmJMutbzptopfG2ACz4AxfZxeUgnDWbBu1hcHyGnNbsDXzkStp9bntK0rpjjQPBgg-1jY8eRWaAcB_V85O45nB_MzOBkHjs9r0q1sGjDHKPhx7WjEaZgiAzZ4IsIMfmKhXFfCy_LUF9yMT24QsWdp66L9H5a1h0hA_940C_gOSIQDClYCc_3NcAcy2w665SAxX4zkbf9KrUNoa2w1tIurssNadIg0Miqo-Q9jwqwCGrZhRa3Zf94d0HVx-aI4KJrBQi3%2Fhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-dunbar-ippm-5g-edge-compute-ip-layer-metrics%252F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce5a45f19804e4ec83d4508d87bea9dc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637395594903951448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1oMRUMShQ8Q8fA9JDhv7pyDVLRPpKamyqLvNHMb51qU%3D&reserved=0>*
> describes the IP Layer metrics and methods to measure the Edge Computing
> Servers running status and environment for IP networks to select the
> optimal Edge Computing server location in 5G Edge Computing (EC)
> environment. This document also describes the method of incorporating those
> measurements with IP routing cost to come up with a more optimal criteria
> in selecting ANYCAST locations.
>
>
>
>
> https://datatracker.ietf.org/doc/draft-dunbar-6man-5g-edge-compute-sticky-service/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F10q2K1AolUwnJQxE-1zdp20SZ9dJ4nGbrfheOMCk6FhMP7cll-lnH4Ele1vAAkXjvGYaXHnAl_WGczRan0zDSIF25BUg7bs9aWtE1gnvQvPt8_qGMdw5gmM3jpAWOXC6_N_neane1LGU-tFdSie6E94aD3LmVxBQnkkB_qnp3glPLwHgMYiU3hGmAJ_yuBK1a2SBOFdr3VmeUxXESfiXy-k0CflGKYdeAnYHNoIGMvbqPWVpWhjEVqqxUpLISwkvVznxIeTcYl6IGePA_y9uGFwvnl_jqU3tClFSPvy1DDEp12JvdoAa6ygDA_rvVmbfW%2Fhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-dunbar-6man-5g-edge-compute-sticky-service%252F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce5a45f19804e4ec83d4508d87bea9dc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637395594903961443%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2cZoGaNIOEVm6twNUFp9aBP%2BYDbWnhEQrPYVVL8Alrg%3D&reserved=0> describes
> a solution of using IPv6 extension header to help Ingress router to stick
> traffic from a UE to the original App Server when the UE moves from one 5G
> Site to another.
>
>
>
>
> https://datatracker.ietf.org/doc/draft-dunbar-idr-5g-edge-compute-app-meta-data/
> describes a new BGP Network Layer Reachability Information (BGP NLRI) Path
> Attribute, AppMetaData, that can distribute the 5G Edge Computing App
> running status and environment, so that other routers in the 5G Local Data
> Network can make intelligent decision on optimized forwarding of flows from
> UEs. The goal is to improve latency and performance for 5G Edge Computing
> services. The extension enables a feature, called soft anchoring, which
> makes one Edge Computing Server at one specific location to be more
> preferred than others for the same application to receive packets from a
> specific source (UE).
>
>
>
> https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1pN4xFsbZmNhUqdhLGnTREMAj8uivXtc4wzAe5JqGqd4rZrJsKGRniQQp0KpmomwEWdnRGFimTXd3kCsWrCfJZK1_IK7-mzNZpLXCnmLbwhM011N3KS_V9ZTbJBsQCpIAz2Se2NJ7c77M8n1w1vTCMA3Mmv9L5yO4SlFI32zj70F_87C-scozGGga61PK-wDmL2JV_2BVvpfnK0YA0ez8WpbnSvQZQsks3bCUl7SQxG2IcuZI4PxNLhA2Y_22SSoaankWjg0sU58se1h4tDt7SrAao_ZcFqSTge-iZYmOyFN996wqXhPh5ZLzGa52Gh2j%2Fhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext%252F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce5a45f19804e4ec83d4508d87bea9dc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637395594903961443%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qb1rHSngDnQYOSDfVH5xyCRnZ9U2WoQ3knWGrUDNcm8%3D&reserved=0>
> describe OSPF extension for the Routers that collect the IP Layer Metrics
> to propagate to all other routers.
>
>
>
> Please let us know if the proposed solutions can solve your use cases.
>
>
>
> Thank you
>
> Linda Dunbar
>
>
>
>
>
>
>
> *From:* rtgwg <rtgwg-bounces@ietf.org> *On Behalf Of *Liyizhou
> *Sent:* Monday, November 2, 2020 1:17 AM
> *To:* rtgwg@ietf.org
> *Cc:* Lifeng (Frank) <frank.lifeng@huawei.com>; Peng Liu <
> liupengyjy@chinamobile.com>; gengliang@chinamobile.com
> *Subject:* Dyncast (dynamic anycast)
>
>
>
> Hi folks,
>
>
>
> We submitted two drafts about dyncast (dynamic anycast).
>
>
>
> draft-geng-rtgwg-cfn-dyncast-ps-usecase
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-geng-rtgwg-cfn-dyncast-ps-usecase%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C868abea8ec7b458427ad08d87f5aa4e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637399374577973883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pkJ6LwZfAAZCHBJpDuRo1dZLFJM1pa2H83S5BZM75UQ%3D&reserved=0>
>
> draft-li-rtgwg-cfn-dyncast-architecture
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-li-rtgwg-cfn-dyncast-architecture%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C868abea8ec7b458427ad08d87f5aa4e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637399374577973883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FcVca03mICRivpgTP6%2FvUIqZnXs47iU%2BJ%2B6XZQUFgf4%3D&reserved=0>
>
>
>
>
>
> Edge computing puts the potential requirements on better load balancing
> among the computing resources hosted on different edges. The number of such
> edges could be thousand or even more depending on where the computing
> resources are located.
>
> The expected approach is to consider both network status and computing
> resources at the same time to determine the best place to forward a new
> computing demand to. Current solution usually uses DNS-like approach,
> select the service instance first (the lowest load or roughly the
> geographically closest instance) and then direct the demand to it
> regardless how good or bad the network path reaching it.
>
>
>
> Anycast based service addressing methodology could be used here to reach
> the best edge in terms of both computation resource and network status at
> the same time. Flow affinity and computing aware routing needs to be
> enhanced in such an anycast architecture. It is called dynamic anycast in
> the drafts.
>
>
>
> If you have any comments or suggestions, please drop us an email.
> Appreciated.
>
>
>
> Regards,
>
> Yizhou
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>