netdev - Re: [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <bc2e1549-e02e-7cdf-b3d5-549c2a8287e8@6wind.com>
Date:   Mon, 30 Jan 2017 17:41:38 +0100
From:   Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:     Roopa Prabhu <roopa@...ulusnetworks.com>
Cc:     David Ahern <dsa@...ulusnetworks.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v3 0/4] net: ipv6: Improve user experience with
 multipath routes

Le 30/01/2017 à 16:45, Roopa Prabhu a écrit :
> On 1/30/17, 3:08 AM, Nicolas Dichtel wrote:
>> Le 30/01/2017 à 00:55, Roopa Prabhu a écrit :
>>> On 1/29/17, 10:02 AM, David Ahern wrote:
>>>> On 1/28/17 6:00 PM, Roopa Prabhu wrote:
>>>>>> 4. Route Appends
>>>>>>    - IPv6 allows nexthops to be appended to an existing route. In this
>>>>>>      case one notification is sent per nexthop added
>>>>> thanks for listing all of these...I think you mentioned this case to me..
>>>>> but I don't remember now why this notification is
>>>>> sent per nexthop added. This is an update to an existing multipath route.
>>>>> so seems like the notification should be a RTM_NEWROUTE with the full RTA_MULTIPATH route
>>>>> (similar to route add)
>>>> It could be; it's a question of what should userspace get -- the full route or the change? Append to me suggests the latter - userspace is told what changed. It is simpler kernel code wise to send the full new route. The append changes were done after our conversation. ;-)
>>> ok, yeah. you listing all the cases here made it more simpler to understand in the context of other notifications :). I would prefer all
>>> RTM_NEWLINK notifications (ie new add or update to an existing route..replace/append), contain the full route via RTA_MULTIPATH.
>> I don't agree. With the previous proposal, you know *exactly* what happens with
>> each notification and this is the primary goal of the notifications. With the
>> last proposal, where RTA_MULTIPATH is used for replace and append, you have the
>> new result, but you don't know what has been done.
>> Usually, notifications are used to notify an event, not the result of an event.
>> If you want the result, you can use the dump cmd.
> 
> what has been done is conveyed by the APPEND and REPLACE flag in the notification. The user only cares about the updated multipath route...
APPEND with a full route is bit ambiguous ;-)

> giving parts of the route has never been very useful... and this is consistent with ipv4.
> 
I don't agree, the user cares about what happens. The dump is here to have the
result if you don't have it already (if the user has a cache, like the libnl,
it's easy to have the result). Daemons that listen nl usually start by a dump
and after they apply the change when they get notifications (they already know
the previous state).

And even if I agree that it's better to be consistent with ipv4, saying "it's
like this in ipv4" is not an argument to made the behavior good/better.
The need to fully remove an ecmp route to add a nexthop in ipv4 is really
painful (see David's example about the 'interface removal' case). And this
functional difference also impacts the notifications.