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.
