NFD

As we discussed in the meeting on Friday that instead of providing extra commands we should have some sort of flags to bypass the rib-manager(nrd). So, right now I am using the following syntax for nfdc.

nfdc [-f] add Name FaceId|FaceUri [cost] [flags]
If -f is given, flags will be ignored, and the next-hop is added directly to fib.

nfdc [-f] del Name FaceId
If -f is given, the next-hop is deleted directly from fib.

Other options are still the same, while add/remove-nexthop commands are not required any more.

The new task describes the updated requirement for nfdc command, which we have discussed and approved during today's call. While we still could have add/def as you described (but I wouldn't insist, since it may create confusions), the new set of commands implicitly and uniquely define specific action: either with Faces (create/destroy), FIB (add/remove-nexthop), or RIB (register/unregister).

Okay, but what does this [-I] and [-C] mean in register? It misses flags as well so I'll them too.

The unregister command cannot work with FaceUri, as the RibManager doesn't support it currently i.e. it doesn't keep track of low level details of faces.

See #1416 on the semantics of -I -C options and how route inheritance flags are specified.

RIB daemon need not know or remember FaceUri.

When FaceUri is specified in place of FaceId in any subcommand, faces/create command is sent to obtain FaceId corresponding to FaceUri.
The FaceId returned from faces/create command is then passed to faces/destroy fib/add-nexthop fib/remove-nexthop rib/register rib/unregister commands.

I know that faceId returned by "create" command can be used to register a prefix or for adding next-hop. But I was specifically talking about the "unregister" command, as we don't need to call "create" in this case. However, if there is any api available to know the faceId(s) associated to given FaceUri, then we may specify FaceUri in unregister as well.

Face may not be needed after destroy/unregister/remove-nexthop.

However, faces/create should still be called when FaceUri is specified in place of FaceId.

Just want to clarify: for destroy/unregister/remove-nexthop commands, if the specified FaceUri or FaceId doesn't exist, calling faces/create will create the face, right? If so, is this the intended behavior? this may not be what is expected by the user.

Specifying FaceUri in place of FaceId creates Face implicitly. This should be written into document.

Junxiao Shi wrote:

Specifying FaceUri in place of FaceId creates Face implicitly. This should be written into document.

I just had a chat with Lan and she explained her concern that if a user mistyped a FaceUri during destroy/unregister/remove-nexthop commands, there is a chance that a new face would be created. This shouldn't happen, as the user didn't ask for it.

I also think that providing FaceUri in destroy/unregister/remove-nexthop commands doesn't help much. If a user cannot remember the faceid of particular faceUri, he can get it from nfd-status.

Please implement exactly according to Task Description.

These concerns are valid but they will be solved in next version when we have faces/query operation.

In that case, why not we don't support FaceURI in unregister command? It's better to create a typo face without user knowledge.

You do need #1416, but two tasks can be completed in same commit.

Although the code that I pushed does take care of "destroy" with faceUri but without face query support it would have one problem. Currently, if a user misspelled the faceUri, a new face is created, nfdc gets the id of the new face and destroys it, so it doesn't create any unnecessary face. But the user also does not get any error message, which is not correct I guess. If a faceUri is not there then we should send a error message to the user. I also checked the ndn-cpp-dev library but couldn't find any method that can destroy face based on Uri.

This is not an error.

After destroying a face by FaceUri, a face with this FaceUri does not exist.
It doesn't matter whether it exists beforehand or not.

faces/destroy command is also considered successful even if FaceId does not exist, because the after-state is same.

I think this behavior is not correct. The system should give useful message that no such FaceId or FaceUri. For e.g. when we do 'rm' for a file that doesn't exist, we get a message that "No such file or directory". Something similar should be done here, but may be in future release.

Idempotence is important for operations over the network.

That is, if two Command Interests with same ControlParameters are sent at the same time, the result should be the same.

Effectively, it takes at least once semantics.

We plan to add a query function in the next release to solve all these problems. Right now, as long as the problems are not significant, we can live with them. Not reporting an error when a non-existent FaceUri is specified should be OK for now. It should be changed once we have the query function.