Re: [PATCH net-next 0/5] net: Extend address label support

[Jakub Kicinski <kuba@kernel.org>]

On Mon, 13 Mar 2023 14:26:56 +0100 Petr Machata wrote:
> > Feels a bit like we're missing motivation for this change.
> > I thought address labels were legacy cruft.  
> 
> The immutability and lack of IPv6 support is seriously limiting, so the
> fact nobody is using this is not that surprising.
> 
> > Also the usual concern about allowing to change things is that some
> > user space will assume it's immutable. The label could until this 
> > set be used as part of a stable key, right?  
> 
> Maybe. But to change a label, you need to be an admin, so yeah, you can
> screw things up if you want to. You could e.g. delete the address
> outright. In the end it should be on me as an admin to run a stack that
> is not stumbling over itself.

I haven't seen that caveat under the "no uAPI-visible regressions"
rule book...  Have you done a github grep for uses of this attr?
I'm guessing that indeed nobody will notice.

> As for the motivation: the use case we are eying in particular is
> advertisement of MLAG anycast addresses. One label would be used to mark
> anycast addresses if they shouldn't be advertised by the routing stack
> yet, a different label for those that can be advertised. Which labels
> mean what would be a protocol between the two daemons involved.

Hm. I see.

> Other userspace stacks might use this to their own ends to annotate sets
> of addresses according to their needs. Like they can today, if the
> sets only involve IPv4 addresses that never migrate from set to set :)

I suspect we may have skipped the feature in v6 for two reasons 
(1) it had no modern use and (2) address label in IPv6 means
the precedence value in address selection, doesn't it?