NFD

RIB Daemon is already able to detect a process failing from face status change notifications.
However, a method needs to be designed for RIB Daemon to know which process is the routing daemon.
Inferring from Origin is not sufficient, because nfdc is able to send Register on behalf of any Origin.

A comment: allowing nfdc to specify origin complicates matters and it seems to defeat the purpose of the origin field. Now a question: suppose we are able to detect the failure of the routing daemon, then should we remove the routes inserted by only that routing daemon or all the routes with that routing daemon's origin (i.e., including the ones inserted by nfdc)? If the former, we need to keep track of which routes are inserted by which process (in addition to the origin).

Answer to note-2:

nfdc's register with specific Origin is intended for testing. Therefore, it's okay to unregister all routes of a routing protocol's Origin when it dies.

I think this task can be rejected. RIB/FIB entries that originated from NLSR will disappear after ~1 hour after NLSR dies (because of the 1~hour expiration lifetime).

That is, we already have a soft state to solve the problem and implementing hard-state may not be necessary.

If we rely on Route expiration, every routing daemon, upon restart after crashing, should request RIB dataset and remove all routes installed by its previous instance.

Even though there is a one-hour expiration time, I think it's still preferable for RIB daemon to remove the routes from the routing process as soon as it dies, if it can detect this event. Question: how does RIB daemon detect whether the routing process has died? I suppose it does not know the face id of the routing process.

Answer to note-6:

A protocol extension would be needed.

A routing daemon SHOULD claim its ownership of an Origin via the rib/claimorigin command.

Parameters of this command include an Origin and a FaceId. RIB daemon MUST verify the signing key of this command owns the Origin.

After this command is accepted, when the specified face is destroyed, RIB daemon MUST erase all Routes carrying the specified Origin.

We have briefly discussed this issue during todays NFD call (July 28, 2014). Protocol extension is really unnecessary. It is possible for NLSR to implement "taking ownership" without defining any new protocol, as Junxiao suggested in note-5: NLSR should request RIB dataset and then request removal all routes with NLSR's origin.

Alex: the question is not about how to remove NLSR's routes, but how to detect NLSR has died. NRD seems face events, but it doesn't know which face corresponds to NLSR, right?

As note-9 said, RIB daemon needs no action when a routing daemon dies.

This means, when a routing daemon crashes, the Routes from this routing daemon remain in the RIB.
When the routing daemon is restarted (eg. by upstart), it should request RIB dataset and take care of the old Routes from its Origin (eg. delete them or reconcile the different).

This approach is better than automatically deleting all Routes, because a short-term routing daemon failure won't affect network operation.
Installed Routes are likely valid even if the routing daemon has failed; if a Route isn't working, forwarding strategy can get around it.
Traffic can still be forwarded during this period without the routing daemon.

The routing daemon is expected to come back soon (before the installed Routes expire).
When it comes back, it should perform an initial route discovery (eg. learn the whole topology in a link-state protocol), and reconcile the difference from the current RIB.

If the suggestion in Note #11 is accepted, then this task needs to be moved to NLSR.