Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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) <
>> [e-mail]> 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 <[e-mail]>
>>> *Sent:* Wednesday, January 12, 2022 5:26 PM
>>> *To:* Robert Raszuk <[e-mail]>
>>> *Cc:* Les Ginsberg (ginsberg) <[e-mail]>; Linda Dunbar <
>>> [e-mail]>; [e-mail]
>>> *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 <[e-mail]> 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 <[e-mail]>
>>> wrote:
>>>
>>> Robert,
>>>
>>>
>>>
>>> Please see inline in green:
>>>
>>>
>>>
>>> *From:* Robert Raszuk <[e-mail]>
>>> *Sent:* Wednesday, January 12, 2022 1:00 PM
>>> *To:* Linda Dunbar <[e-mail]>
>>> *Cc:* Les Ginsberg (ginsberg) <[e-mail]>; [e-mail]
>>> *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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>> --
>>>
>>> [image: Image removed by sender.] <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions Architect *
>>>
>>> *Email [e-mail] <[e-mail]>*
>>>
>>> *M 301 502-1347*
>>>
>>>
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email [e-mail] <[e-mail]>*
>>
>>
>>
>> *M 301 502-1347*
>>
>>