NFD

I have this in patchset1:

/** \brief removes the NextHop record for face
 *  \return whether \p entry should be erased
 */
bool
Fib::removeNextHop(Entry& entry, const Face& face);

I don't like this API, the return value semantics are quite unusual and counter-intuitive... I don't see the need for a return value at all... the caller can just do

if (!entry->hasNextHops()) {
  doSomething();
}

much more self-explanatory, and removes the need for a well-named intermediate boolean variable to describe the return value of this function.
And if you remove the return value, this function becomes just a wrapper for Entry::removeNextHop(), and can thus be eliminated completely.

The reason for having Fib::removeNextHop function in FIB is that, how cleanup-on-face-removal should be performed is a logic procedure of the FIB.
The cleanup procedure cleanupOnFaceRemoval is only responsible for enumerating the name tree and invoking the visitor in FIB and PIT.

I recognize the semantic problem in this API, and another weakness: NameTree::eraseEntryIfEmpty is called more than necessary on the same entry, and the containers for to-be-erased FIB/PIT entries are too large.
To solve both problems:

1. Fib::removeNextHop and Pit::deleteInOutRecords can internally erase the FIB/PIT entry when desired (detach from name tree entry and decrement size counter), but they shouldn't invoke NameTree::eraseEntryIfEmpty. They return void.
2. In cleanupOnFaceRemoval, after a name tree entry is processed through both FIB and PIT, if all FIB/PIT entries are deleted, the name tree entry is placed into a container. Name tree entries in this container is passed to NameTree::eraseEntryIfEmpty at the end.

Why would you keep PIT entry?

Why would you keep PIT entry?

As stated in note-1, I'm unsure about the implication of deleting the PIT entry when all in-records and out-records are removed due to faces being destroyed.
For the first Change, I'll keep the PIT entry to minimize changes, so that dependent tasks can proceed.

Once I understand the implication of deleting the PIT entry and can confirm it's safe to do so, another Change will perform the deletion.

An Interest table entry serves three purposes:

• to return Data back to the downstream
• to detect Interest loop
• to store information for strategy's measurements

I think it's safe to delete an Interest table entry when it contains neither in-record nor out-record, because such an empty Interest table entry is useless for the first and second purposes, and every strategy is designed to operate correctly even if StrategyInfo is lost (due to the requirement of runtime strategy change).

For an Interest table entry that contains no in-record but still has out-record, we notice that this is exactly the case when a pending Interest has been satisfied (outgoing Data pipeline clears in-records). Such entry is useless for the first purpose, but is still useful for the second and third purposes. If we delete such entry immediately, it would be necessary to insert Nonces into DNL. Thus, in this situation, it's better to set straggler timer on the entry.

For an Interest table entry that contains no out-record but still has in-record, despite this state is same as when the strategy rejects a pending Interest, I think the best course of action is to notify the strategy. Recall that in the situation here, the last out-record is deleted due to a face being destroyed; this is same as (or worse than) a temporary link failure, and the strategy should be given an opportunity to retry the Interest on an alternate path.