Re: [PATCH net-next 7/8] mpls: Multicast route table change notifications

[ebiederm@xmission.com (Eric W. Biederman)]

roopa <roopa@cumulusnetworks.com> writes:

> On 2/25/15, 9:19 AM, Eric W. Biederman wrote:
>> Unlike IPv4 this code notifies on all cases where mpls routes
>> are added or removed as that was the simplest to implement.
>>
>> In particular routes being removed because a network interface
>> goes down or is removed are notified about.  Are there technical
>> arguments for handling this differently ? Userspace developers
>> don't particularly like the way IPv4 handles route removal
>> on ifdown.
> that is true. However, from previous emails on this topic on netdev,
> there is no reason to notify these deletes to userspace thereby creating a
> notification storm
> when userspace can figure this out. Which seems like a valid reason.
> (Your approach resembles IPv6 which does generate these notifications and
> userspace is usually happy with this).

Grr.  There is an even better way to do this.

The semantically best way to handle this is to simply not use routes for
forwarding where the network inteface is down, the carrier is down, or
the network device has gone away for forwarding.

Apparently there are some multi-path scenearios that already do this
legitimately, and routes going away auto-matically can cause userspace
other kinds of problems.

In MPLS I especially don't want to free the routing table slot until I
know that the change has propagated in the network and I can be
reasonably confident that no-one will send me traffic on that label.
Otherwise there is a chance the label will be reused too soon.

Grumble.  That is a code change I need to make.  Grumble.

I also need to look and see if those multi-path scenarios report a next
hop as dead or just rely on the network interface state (which I think
it is) to be sufficient information relayed to userspace

Eric