On 1/29/17, 6:57 PM, David Ahern wrote:
> On 1/29/17 7:20 PM, Roopa Prabhu wrote:
>>> 2. Delete - 1 notification for each hop for all combinations of delete
>>> commands
>> here I was trying to say, for people deleting the full multipath route, you
>> should send a RTA_MULTIPATH.
> The only way to do that is to call inet6_rt_notify() *before* the route
> delete work has been done in fib6_del_route. Right now it is called at the
> end - after all sibling associations have been dropped, a time in which it
> can no longer fill in RTA_MULTIPATH.
>
> fib6_del_route function does not have any failure paths and is called with
> the write lock held, so moving the notification might be ok. But it also
> means ignoring all subsequent failures from fib6_del, again which might be ok
> since the only failure is ENOENT which can not happen if we are walking the
> sibling list.
>
>
>> For the odd case of ipv6 single nexthop delete, you can continue to send a
>> single nexthop delete (like today ..without RTA_MULTIPATH)
>> because there is no other way to notify a single nexthop delete with a
>> RTM_DELROUTE.
>>
>> The reason I say this is because: keeping future in mind, this will make
>> things consistent for majority of people who will
>> start using RTA_MULTIPATH for both ipv4 and ipv6 for adds and deletes
>> (requests/notifications and dumps) the same way.
>> single next hop delete will just be around because of fear of breaking
>> existing applications.
> Single next hop delete will be around because IPv6 allows it -- and because
> IPv4 needs to support it.
>
understand single next hop delete for ipv6 will be around..and my only point
was to leave it around but not optimize for that case.
I don't think we should support single nexthop delete in ipv4 (I have not seen
a requirement for that)... ipv4 is good as it is right now.
the additional complexity is not needed.
