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

[Andy Gospodarek <gospo@cumulusnetworks.com>]

On Thu, Feb 26, 2015 at 07:12:34AM -0800, roopa wrote:
> On 2/26/15, 6:03 AM, Eric W. Biederman wrote:
> >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.
> 
> agreed, And we have an internal patch that does this for regular routing
> on carrier down (which we will upstream soon).
Yep, I should be able to easily forward-port it from 3.17 to net-next
without much issue.  Eric feel free to email me directly if you want to
see what I've got now.

> >
> >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.
> ack
> >
> >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
> >
> they are marked DEAD on ifdown today (AFAIR they dont generate a
> notification in IPv4)  and are skipped during route lookup.
> Only when all the nexthops in a multi-path route are dead, is the route
> multipath route declared dead
> and is deleted today (with no notification to userspace in the IPv4 case).
> 
> Thanks,
> Roopa
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html