Hi Linda and Jeffrey I have worked on designs in the using Anycast application VIPs for fast failover recovery and reading through my notes what we found was that using Anycast failover from network fault recovered much better instantly based on Core / DC convergence for IP application traffic as compared to using DNS GEO load balancing relying on DNS to provide a different address in failover scenario is much slower and resulted in
As Jeffrey pointed out most all router vendors support flow based ECMP load balancing default and not per packet to avoid out of order packets issues and the session does have affinity to the path for the duration of the session remains on the hashed path. So when the application VIP from the primary DC fails the session is reset TCP RST and the application flow reestablished on the next closest proximity data center. So the issue that arise with Anycast design to be careful of is the core exist point distance to each DC exit point from the core must have enough of a variation in the metric or will result in session instability and flapping as traffic patterns change or links within the core failover the session may get constantly reset. Recommend that within region or close proximity to not rely on Anycast as that can result in instability. This is described in detail in the link below and matches my Anycast design experiences. https://weborigin.cachefly.com/anycast-think-before-you-talk-part-ii/ In Linda’s 5G DC POP architecture as it’s regional and nominal metric difference or ECMP paths iBGP tie breaker or iBGP ECMP load sharing per flow load balancing in the core the problem is with the UE flipping between DC POPs TCP reset upon DC POP failure however if there are multiple DC POP ECMP path and multiple DC failures occur the session could be reset a few times. As the flow has affinity to the path it’s on flow based load balancing only when the ECMP hashed path used for the DC flow fails would the TCP session reset and fail to alternate POP but still should be instantaneously. The link below talks about the issues related to relying on application server and content load balancers to use stickiness and issues as it relies on a cookie sent to the browser and in some cases the browser could block the cookie so has to accepted by the client. https://stackoverflow.com/questions/53703163/aws-alb-sticky-cookie-issue This link talks about Citrix Netscaler load balancer which I am familiar with the issues related to persistence for a flow and can yield uneven load balancing over the core links polarization of flows. - Persistence – When enabled, persistence (by definition) creates uneven loading because the NetScaler appliance must direct requests from a specific client to a specific server. Only unique or expired clients get load balanced according to the load balancing method. https://support.citrix.com/article/CTX120542 Kind Regards Gyan On Thu, Nov 11, 2021 at 12:44 PM Linda Dunbar <[email protected]> wrote: > Forget to mention: > > The local DNS to schedule traffic from different ingress routers to > different Load Balancers can become a bottleneck if network condition is > not leveraged. > > > Linda > > _____________________________________________ > *From:* Linda Dunbar > *Sent:* Thursday, November 11, 2021 9:18 AM > *To:* Jeffrey (Zhaohui) Zhang <[email protected]>; [email protected]; 'IPv6 > List' <[email protected]>; 'idr@ietf. org' <[email protected]> > *Subject:* RE: Comments about draft-dunbar-lsr-5g-edge-compute, > -idr-5g-edge-compute-app-meta-data and -6man-5g-edge-compute-sticky-service > > > 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* > <https://pc.nanog.org/static/published/meetings/NANOG77/2082/20191030_Wang_An_Architecture_Of_v1.pdf> > > << OLE Object: Picture (Device Independent Bitmap) >> > 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]>; Kaippallimalil John < > [email protected]>; IPv6 List <[email protected]>; idr@ietf. > org <[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 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
