NFD

I notice that @Wentao Shang added ForwardingFlags field into PrefixRegOptions.
Please explain the reason.

It is still defined (as optional) in wiki's description of the protocol... Adding definition of the ForwardingFlags (nonNegativeInteger) was my suggestion, since it was not defined anywhere else.

In RFC, an optional field of a structure means that this field can be present or absent in the structure, but every implementation still needs to understand and process it.

NFD FIB Management protocol does not need ForwardingFlags.

ForwardingFlags should be defined in NRD Prefix Registration protocol.

NFD FIB Management protocol (rev6) is missing one feature: delete a FIB entry.

prefixunreg command removes a nexthop from a FIB entry.
When the last nexthop is removed, the FIB entry is still retained.
Therefore, once a FIB entry is created, it's there forever.

The alternative is, removing the last nexthop deletes the FIB entry.
This makes it impossible to create a FIB entry that has zero nexthop.

I propose to take the alternative: removing the last nexthop deletes the FIB entry.
This is the common case.
If there's a need for having a FIB entry with zero nexthop, a separate command could be defined.

Yes. I like this common sense approach (remove the last next hop removes the FIB entry). I have updated FibMgmt wiki and also created a template for NRD wiki page.

There is still a problem: FIB entry not only contains the nexthop list, but also indicates a strategy choice.
If a FIB entry contains a strategy choice, but its last nexthop is removed, deleting the FIB entry would also delete the strategy choice.

On the other side, if prefixstrategy command causes insertion of a FIB entry, the nexthop list is copied from its parent.
NRD does not know the existence of a new FIB entry, so it would not update this nexthop list.

I also created a template for NRD wiki page.

NRD does not belong in this project.
A separate project should be created for NRD, and this page should be moved to NRD project.

Wait a minute. I thought strategy selection is not directly tight to FIB entries. We have (should have) additional table that keeps mapping between namespace and strategy and this table is consulted every time a new FIB entry is created (not parent FIB entry, in UML, there is a map in FibManager for that).

1. strategy table defines:
   • / uses original strategy
   • /A uses broadcast strategy
2. Removing the last nexthop of /A deletes the FIB entry
3. Interest /A/B matches FIB entry / which says "original strategy", but it should be processed by broadcast strategy.

FIB entry insertion and deletion is now explicit, as decided in 20140129 conference call.

I will do an update of the FIB management protocol. Having separate definitions for each operation is overkill, I want to have just a generic FibManagementOptions and then define which fields are required for each operation.

Also. I think we should update the base protocol as well (may be later). Instead of just /localhost/nfd/<verb>/..., we should have /localhost/nfd/<management-module>/<verb>/.... For example, for FIB management it would be /localhost/nfd/fib/nexthop-insert.

One more update of the spec: re-assigned numbers. The types are now assigned from the range specifically reserved for forwarding daemon use (I have updated TLV spec for that). To simplify our future debugging, the type assignment right now is non-overlapping.

20140216 conference call discussed the reason that apps should register prefix with NRD, not with NFD:

• RIB maintenance work is offloaded to NRD: inheritance, etc
• if app registers prefix with NFD, the changes may not be consistent with changes made by routing protocols

NRD should be considered as "part of the forwarding platform", and they must run together.
If either NFD or NRD fails, "forwarding platform" also fails.

In the future, NFD and NRD might be combined into one process, under different threads.