netdev - Re: [PATCH iproute2] vxlan: add support for flowlab inherit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <02331777-cf56-4491-91c2-df76eab88032@gmail.com>
Date: Mon, 29 Jan 2024 11:44:32 -0700
From: David Ahern <dsahern@...il.com>
To: Ido Schimmel <idosch@...sch.org>
Cc: Vincent Bernat <vincent@...nat.ch>, Alce Lafranque <alce@...ranque.net>,
 netdev@...r.kernel.org, stephen@...workplumber.org
Subject: Re: [PATCH iproute2] vxlan: add support for flowlab inherit

On 1/28/24 5:35 AM, Ido Schimmel wrote:
> On Fri, Jan 26, 2024 at 10:17:36AM -0700, David Ahern wrote:
>> On 1/25/24 11:28 PM, Vincent Bernat wrote:
>>> Honestly, I have a hard time finding a real downside. The day we need to
>>> specify both a value and a policy, it will still be time to introduce a
>>> new keyword. For now, it seems better to be consistent with the other
>>> protocols and with the other keywords (ttl, for example) using the same
>>> approach.
>>
>> ok. let's move forward without the new keyword with the understanding it
>> is not perfect, but at least consistent across commands should a problem
>> arise. Consistency allows simpler workarounds.
> 
> I find it weird that the argument for the current approach is
> consistency when the commands are already inconsistent:

I am 5+ years removed from working with tunneling protocols on a regular
basis, and the brain cells holding the details and nuances of vxlan,
geneve, etc command lines have long since been recycled. My attempt here
is to build a consensus on how to move forward by offering some guiding
principles - like the kernel API puts absolutely no constraint on
iproute2 command line syntax and that a package like iproute2 should be
consistent across commands.

This is open source and is best served by voices chiming in with
detailed perspectives. Lacking a decisive reason to choose one option
over another, I will err on the side of consistency. Dealing with subtle
differences in command lines is a real pain to users and it is a shame
that what exists is so radically different.