Eduard, The issue is present not in link/device case, if well implemented - fast rehash takes care of updating forwarding within a number of ms. The problem is with “gray” failures, when the link in question is UP from routing/forwarding prospective but drops traffic (mostly occasionally and when a HW bug occurs has a distinct flow attributes).
In many large DC fabrics, the majority of the traffic is east-west, between end-points that aren’t anycast. In such deployments - the solution solves issues rather elegantly and without any interventions from the operator. The issues/side effects are well understood and will be documented. The best way to receive RTGWG emails is well… to subscribe to RTGWG ;-) Cheers, Jeff > On Aug 1, 2021, at 09:47, Vasilenko Eduard <[email protected]> > wrote: > > > Hi Alexander, > > Have I understood your presentation right? > The client SHOULD change IPv6 flow label after SYN RTO to have a chance to be > moved to the working path inside DC fabric (if DC fabric supports flow label > for hash calculation) > But at the same time > The client SHOULD NOT change the IPv6 flow label after SYN RTO to avoid being > switched to a different TCP proxy engine. > > Looks like a deadlock, especially if both things should happen for the same > traffic: > it should reach DC fabric > and > it should be hash load-balanced between different TCP proxy engines (or > applications) inside DC Fabric. > > I see one bad solution (“Disable Flow Label”): > Routers up to TCP proxy engine SHOULD be configured not to use flow label (by > the way these are all routers on the Internet), > TCP flow engines SHOULD be outside of the DC Fabric (CLOS) – probably in > front of it. > Routers/Switches inside DC Fabric SHOULD use flow labels. > > I see another bad solution (“Disable Anycast”): > Disable anycast on routers in principle, use only stateful LB. > > > It has been commented in the chat that Anycast is not possible in principle > for stateful connection. It is too general a statement. > Anycast is just not compatible with Flow Label. It is not a problem for IPv4 > anycast even if the connection is stateful (TCP) because 5-tuple for hash > would not change. > Hence, IPv6 anycast has become dead at the time when Flow Label change has > been added in LINUX for active TCP session. > > Among 3 thins: > - Anycast > - Flow Label load balancing (basic Flow Label functionality) > - Flow Label change on the active session for application to be more > active in new path search > You have to choose which one to kill – all 3 are not compatible with each > other at the same. > I vote to disable Flow Label change in LINUX. Then wait till the network > would fix itself. > We have so many fancy TE tools our days. A broken link or a broken node could > be excluded from routing for 50ms. > > PS: I am not subscribed to the RTGWG alias, please keep me on a copy of this > thread. > <image001.png> > Best Regards > Eduard Vasilenko > Senior Architect > Europe Standardization & Industry Development Department > Tel: +7(985) 910-1105, +7(916) 800-5506 > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
