And just to provide a sound alternative to the objective of this work. Please consider using Traefik - https://traefik.io/
Thx, R. On Thu, Jan 13, 2022 at 11:56 AM Robert Raszuk <[email protected]> wrote: > Gyan, > > I see what the draft is trying to do now. /* I did not even consider this > for the reason described below. */ > > But what you wrote requires little correction: > > "So now the server you are on gets overloaded and a site cost gets > advertised in the IGP at which point the connection receives a TCP reset" > > if you *s/connection/all connections/* then you quickly realize that what > is proposed here is a disaster. > > Breaking all existing flows going to one LB to suddenly timeout and all go > to the other LB(s) is never a technique any one would seriously deploy in a > production network. > > Leave alone that doing that has potential to immediately overload the > other LB(s)/server(s) too. > > For me the conclusion is that IGP transport level is not the proper layer > to address the requirement. > > Cheers, > Robert. > > > On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra <[email protected]> wrote: > >> >> Hi Les >> >> Agreed. >> >> My thoughts are that the context of the draft is based on an Anycast VIP >> address of a server which is proximity based load balancing and not >> necessarily ECMP/UCMP and only if the proximity is the same for multiple >> paths to the Anycast VIP would there be a ECMP/UCMP possibility. >> >> Let’s say if it’s proximity based and one path is preferred, the flow >> will take that path. So now the server you are on gets overloaded and a >> site cost gets advertised in the IGP at which point the connection receives >> a TCP reset and flow re-establishes on the alternate path based on the site >> cost and remains there until the server goes down or gets overloaded or a >> better path comes along. >> >> For ECMP case, ECMP has flow affinity so the flow will stay on the same >> path long lived until the connection terminates. >> >> So now in ECMP case the flow hashed to a path and maintains its affinity >> to that path. Now all of sudden the server gets overloaded and we get a >> better site cost advertised. So now the session terminates on current path >> and establishes again on the Anycast VIP new path based on the site cost >> advertised. >> >> The failover I believe results in the user refreshing their browser which >> is better than hanging. >> >> As the VIP prefix is the only one that experiences reconvergence on new >> path based on site cost if there is any instability with the servers that >> will be reflected to the IGP Anycast prefix as well. >> >> Is that a good or bad thing. I think if you had to pick your poison as >> here the issue Linda is trying to solve is a server issue but leveraging >> the IGP to force re-convergence when the server is in a half baked state >> meaning it’s busy and connections are being dropped or very slow QOE for >> end user. If you did nothing and let it ride the the user would be stuck >> on a bad connection. >> >> So this solution dynamically fixed the issue. >> >> As far as oscillation that is not a big deal as you are in a much worse >> off state connected to a dying server on its last leg as far as memory and >> CPU. >> >> This solution I can see can apply to any client / server connection and >> not just 5G and can be used by enterprises as well as SP for their >> customers to have an drastically improved QOE. >> >> I saw some feedback on the TLV and I think once that is all worked out I >> am in favor of advancing this draft. >> >> Kind Regards >> >> Gyan >> >> >> On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) < >> [email protected]> wrote: >> >>> Gyan – >>> >>> >>> >>> The difference between ECMP and UCMP is not significant in this >>> discussion. >>> >>> I don’t want to speak for Robert, but for me his point was that IGPs can >>> do “multipath” well – but this does not translate into managing flows. >>> >>> Please see my other responses on this thread. >>> >>> >>> >>> Thanx. >>> >>> >>> >>> Les >>> >>> >>> >>> >>> >>> *From:* Gyan Mishra <[email protected]> >>> *Sent:* Wednesday, January 12, 2022 5:26 PM >>> *To:* Robert Raszuk <[email protected]> >>> *Cc:* Les Ginsberg (ginsberg) <[email protected]>; Linda Dunbar < >>> [email protected]>; [email protected] >>> *Subject:* Re: [Lsr] Seeking feedback to the revised >>> draft-dunbar-lsr-5g-edge-compute >>> >>> >>> >>> >>> >>> Robert >>> >>> >>> >>> Here are a few examples of UCMP drafts below used in core and data >>> center use cases. >>> >>> >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15 >>> >>> >>> >>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02 >>> >>> >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth >>> >>> >>> >>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz >>> >>> >>> >>> >>> >>> >>> >>> There are many use cases in routing for unequal cost load balancing >>> capabilities. >>> >>> >>> >>> Kind Regards >>> >>> >>> >>> Gyan >>> >>> >>> >>> On Wed, Jan 12, 2022 at 2:23 PM Robert Raszuk <[email protected]> wrote: >>> >>> Linda, >>> >>> >>> >>> > IGP has been used for the Multi-path computation for a long time >>> >>> >>> >>> IGP can and does ECMP well. Moreover, injecting metric of anycast server >>> destination plays no role in it as all paths would inherit that external to >>> the IGP cost. >>> >>> >>> >>> Unequal cost load balancing or intelligent traffic spread has always >>> been done at the application layer *for example MPLS* >>> >>> >>> >>> Thx a lot, >>> >>> R. >>> >>> >>> >>> On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar <[email protected]> >>> wrote: >>> >>> Robert, >>> >>> >>> >>> Please see inline in green: >>> >>> >>> >>> *From:* Robert Raszuk <[email protected]> >>> *Sent:* Wednesday, January 12, 2022 1:00 PM >>> *To:* Linda Dunbar <[email protected]> >>> *Cc:* Les Ginsberg (ginsberg) <[email protected]>; [email protected] >>> *Subject:* Re: [Lsr] Seeking feedback to the revised >>> draft-dunbar-lsr-5g-edge-compute >>> >>> >>> >>> Hi Linda, >>> >>> >>> >>> *[LES:] It is my opinion that what you propose will not achieve your >>> goals – in part because IGPs only influence forwarding on a per packet >>> basis – not a per flow/connection basis.* >>> >>> *[Linda] Most vendors do support flow based ECMP, with Shortest Path >>> computed by attributes advertised by IGP.* >>> >>> >>> >>> I am with Les here. ECMP has nothing to do with his point. >>> >>> >>> >>> [Linda] Les said that “IGP only influence forwarding on a per packet >>> basis”. I am saying that vendors supporting “forwarding per flow” with >>> equal cost computed by IGP implies that forwarding on modern routers are >>> no longer purely per packet basis. >>> >>> >>> >>> >>> >>> Draft says: >>> >>> >>> >>> *When those multiple server instances share one IP address (ANYCAST), >>> the transient network and load conditions can be incorporated in selecting >>> an optimal path among server instances for UEs.* >>> >>> >>> >>> So if we apply any new metric to indicate load of a single anycast >>> address how is this going to help anything ? >>> >>> >>> >>> [Linda] The “Load” or “Aggregated Site Cost” is to differentiate >>> multiple paths with the same routing distance. >>> >>> >>> >>> >>> >>> You would need a mechanism where the network is smart and say per >>> src-dst tuple or more spreads the traffic. IGP does not play that game >>> today I am afraid. >>> >>> [Linda] There is one SRC and multiple paths to one DST. IGP has been >>> used for the Multi-path computation for a long time. >>> >>> >>> >>> Thank you, Linda >>> >>> >>> >>> Thx a lot, >>> R. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr >>> >>> -- >>> >>> [image: Image removed by sender.] <http://www.verizon.com/> >>> >>> *Gyan Mishra* >>> >>> *Network Solutions Architect * >>> >>> *Email [email protected] <[email protected]>* >>> >>> *M 301 502-1347* >>> >>> >>> >> -- >> >> <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
