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 <[email protected]> Sent: Friday, July 29, 2022 3:26 AM To: Linda Dunbar <[email protected]>; RTGWG <[email protected]>; idr <[email protected]> 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 ________________________________ [email protected]<mailto:[email protected]> From: Linda Dunbar<mailto:[email protected]> Date: 2022-06-30 05:49 To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
