Re: [Idr] What are the solutions to address large number of routes convergence caused by Cloud Infrastructure failure described in draft-ietf-rtgwg-net2cloud-problem-statement?

[Linda Dunbar <[e-mail]>]

ChongFeng,

When a UE roams from one UPF to another and keep the same IP address, a closer Edge DC might have the service instances that the UE is accessing.
Depending on the stickiness of the service, a very small number of services might need to stick to the original service instance closer to the UPF before the moving.
See this draft for detail: https://datatracker.ietf.org/doc/draft-dunbar-6man-5g-edge-compute-sticky-service/

Linda




From: Chongfeng Xie <[e-mail]>
Sent: Friday, July 29, 2022 3:26 AM
To: Linda Dunbar <[e-mail]>; RTGWG <[e-mail]>; idr <[e-mail]>
Subject: Re: [Idr] What are the solutions to address large number of routes convergence caused by Cloud Infrastructure failure described in draft-ietf-rtgwg-net2cloud-problem-statement?


Hi，Linda,
You mentioned the mobile case in your presentation yesterday.  When the mobile terminal roams from one BS to another BS,  because UPF is the access anchor point, the address of the termianl will not change as long as it is continuous served by the same UPF of mobile network, is ther any specific requirement or effect to Net2cloud in this case？

Best regards
Chongfeng
________________________________
[e-mail]<mailto:[e-mail]>

From: Linda Dunbar<mailto:[e-mail]>
Date: 2022-06-30 05:49
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [Idr] What are the solutions to address large number of routes convergence caused by Cloud Infrastructure failure described in draft-ietf-rtgwg-net2cloud-problem-statement?
BGP experts:

The Section 3.2 of https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-net2cloud-problem-statement%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C7fa1ad7f0a674005675a08da713bea99%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637946799410688623%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=51LhdN4fM2i1DEBC51z4piqNe6U%2BLTFjzAzpG9RBZMM%3D&reserved=0> describes a problem of a Cloud DC infrastructure failure, that may lead to massive route changes.

   As described in RFC7938, Cloud DC BGP might not have an IGP to route
   around link/node failures within the Assess. Fiber-cut is not uncommon
   within Cloud DCs or between sites. Sometimes, an entire cloud data
   center goes dark caused by a variety of reasons, such as too many
   changes and updates at once, changes of outside of maintenance
   windows, cybersecurity threats attacks, cooling failures,
   insufficient backup power, etc. When those events happen, massive
   numbers of routes need to be changed.

   The large number of routes switching over to another site can also
   cause overloading that triggers more failures.

   In addition, the routes (IP addresses) in a Cloud DC cannot be
   aggregated nicely, triggering very large number of BGP UPDATE
   messages when a failure occurs.

EVPN [RFC7432] defined mass withdraw mechanism to signal a large number  of routes being changed to remote PE nodes.

Is Mass withdrawn supported by all networks?

Thank you
Linda Dunbar