Re: Comments about draft-dunbar-lsr-5g-edge-compute, -idr-5g-edge-compute-app-meta-data and -6man-5g-edge-compute-sticky-service

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 <linda.dunbar@futurewei.com>
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 <zzhang@juniper.net>; lsr@ietf.org; 'IPv6
> List' <ipv6@ietf.org>; 'idr@ietf. org' <idr@ietf.org>
> *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 <zzhang@juniper.net>
> Sent: Thursday, November 11, 2021 8:08 AM
> To: Linda Dunbar <linda.dunbar@futurewei.com>; lsr@ietf.org; 'IPv6 List' <
> ipv6@ietf.org>; 'idr@ietf. org' <idr@ietf.org>
> 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&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C36cfe5852ea24a8f730108d9a51ca3bf%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637722364713687643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ILSLOrYcIROMHb%2FxCI2AqMHm%2FAHQA6BXGoJvArZaj30%3D&amp;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 <linda.dunbar@futurewei.com>; Kaippallimalil John <
> john.kaippallimalil@FUTUREWEI.COM>; IPv6 List <ipv6@ietf.org>; idr@ietf.
> org <idr@ietf.org>
> 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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*