Jeffrey, You are not alone in thinking the problem is best solved at "app layer". My sister working for Cloud Operator's Layer4 & Layer 7 Load balancer division debated with me all the time.
They can: - deploy many load balancers, each managing traffic among many active servers. - local DNS to schedule traffic from different ingress routers to different Load Balancers As pointed in this NANOG presentation: https://pc.nanog.org/static/published/meetings/NANOG77/2082/20191030_Wang_An_Architecture_Of_v1.pdf Leveraging the network condition to optimize traffic can solve those issues. >From the forwarding perspective, it is same as introducing TE metrics into >Path computation. When TE metrics, bandwidth, etc. change, the path change >accordingly. Linda Dunbar -----Original Message----- From: Jeffrey (Zhaohui) Zhang <[email protected]> Sent: Thursday, November 11, 2021 8:08 AM To: Linda Dunbar <[email protected]>; [email protected]; 'IPv6 List' <[email protected]>; 'idr@ietf. org' <[email protected]> Subject: Comments about draft-dunbar-lsr-5g-edge-compute, -idr-5g-edge-compute-app-meta-data and -6man-5g-edge-compute-sticky-service Hi, I did not have time to comment during today's LSR session so I am bringing this to the list. I am also adding IDR and 6man lists because all these three drafts are about the same use case. There were a long email discussion on the 6man draft here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fipv6%2F4rw-pBcNZN7mzkArjUtVUzLcQJU%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C36cfe5852ea24a8f730108d9a51ca3bf%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637722364713687643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ILSLOrYcIROMHb%2FxCI2AqMHm%2FAHQA6BXGoJvArZaj30%3D&reserved=0 back in March. There are basically two problems here: 1. which server to pick 2. how to stick to the same server when a UE (mobile device) moves The long discussion on the 6man list is mainly focused on #2. I don't know if we can say there was a conclusion, but some people (me included) believe that both problems are best solved at "app layer" instead of routing layer - just put a load balancer next to the 5G UPF. Jeffrey -----Original Message----- From: Jeffrey (Zhaohui) Zhang Sent: Thursday, March 25, 2021 3:46 PM To: Linda Dunbar <[email protected]<mailto:[email protected]>>; Kaippallimalil John <[email protected]<mailto:[email protected]>>; IPv6 List <[email protected]<mailto:[email protected]>>; idr@ietf. org <[email protected]<mailto:[email protected]>> Subject: questions about draft-dunbar-idr-5g-edge-compute-app-meta-data and draft-dunbar-6man-5g-edge-compute-sticky-service Hi Linda, John, I have the following questions. The two related drafts listed the following three problems respectively: 1.3. Problem#1: ANYCAST in 5G EC Environment.............. 6 1.4. Problem #2: Unbalanced Anycast Distribution due to UE Mobility.................................................. 7 1.5. Problem 3: Application Server Relocation............. 7 1.2. Problem #1: ANYCAST in 5G EC Environment.............. 4 1.3. Problem #2: sticking to original App Server........... 5 1.4. Problem #3: Application Server Relocation............. 5 Why is problem #2 different in the two drafts? Is it true that none of the two drafts address problem #3? The idr draft talk about "soft anchoring" problem and solution - how is that different from the "sticky service"? Thanks. Jeffrey Juniper Business Use Only
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
