Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
From:   Jay Vosburgh <jay.vosburgh@canonical.com>
To:     Jakub Kicinski <kuba@kernel.org>
cc:     David Ahern <dsahern@kernel.org>,
        Sun Shouxin <sunshouxin@chinatelecom.cn>, vfalico@gmail.com,
        andy@greyhouse.net, davem@davemloft.net, pabeni@redhat.com,
        yoshfuji@linux-ipv6.org, oliver@neukum.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, huyd12@chinatelecom.cn
Subject: Re: [PATCH v6 0/4] Add support for IPV6 RLB to balance-alb mode
In-reply-to: <20220323083332.54dc0a6e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
References: <20220323120906.42692-1-sunshouxin@chinatelecom.cn> <7288faa9-0bb1-4538-606d-3366a7a02da5@kernel.org> <20220323083332.54dc0a6e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Comments: In-reply-to Jakub Kicinski <kuba@kernel.org>
   message dated "Wed, 23 Mar 2022 08:33:32 -0700."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4912.1648053525.1@famine>
Date:   Wed, 23 Mar 2022 09:38:45 -0700
Message-ID: <4913.1648053525@famine>
Precedence: bulk

Jakub Kicinski <kuba@kernel.org> wrote:

>On Wed, 23 Mar 2022 08:35:03 -0600 David Ahern wrote:
>> On 3/23/22 6:09 AM, Sun Shouxin wrote:
>> > This patch is implementing IPV6 RLB for balance-alb mode.
>>
>> net-next is closed, so this set needs to be delayed until it re-opens.
>
>What I'm not sure of is why this gets reposted after Jiri nacked
>it. A conclusion needs to be reached on whether we want this
>functionality in the first place. Or someone needs to explain 
>to me what the conclusion is if I'm not reading the room right :)

	The summary (from my perspective) is that the alb/rlb technology
more or less predates LACP, and is a complicated method to implement
load balancing across a set of local network peers.  The existing
implementation for IPv4 uses per-peer tailored ARP messages to "assign"
particular peers on the subnet to particular bonding interfaces.  I do
encounter users employing the alb/rlb mode, but it is uncommon; LACP is
by far the most common mode that I see, with active-backup a distant
second.

	The only real advantage alb/rlb has over LACP is that the
balance is done via traffic monitoring (i.e., assigning new peers to the
least busy bond interface, with periodic rebalances) instead of a hash
as with LACP.  In principle, some traffic patterns may end up with hash
collisions on LACP, but will be more evenly balanced via the alb/rlb
logic (but this hasn't been mentioned by the submitter that I recall).
The alb/rlb logic also balances all traffic that will transit through a
given router together (because it works via magic ARPs), so the scope of
its utility is limited.

	As much as I'm all in favor of IPv6 being a first class citizen,
I haven't seen a compelling use case or significant advantage over LACP
stated for alb/rlb over IPv6 that justifies the complexity of the
implementation that will need to be maintained going forward.

	-J

---
	-Jay Vosburgh, jay.vosburgh@canonical.com