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

[Gyan Mishra <[e-mail]>]

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*