On 1/30/17, 3:08 AM, Nicolas Dichtel wrote:

Le 30/01/2017 à 00:55, Roopa Prabhu a écrit :

quoted

On 1/29/17, 10:02 AM, David Ahern wrote:

quoted

On 1/28/17 6:00 PM, Roopa Prabhu wrote:

quoted

quoted

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...
giving parts of the route has never been very useful... and this is consistent with ipv4.