nfdc allows FaceUri in place of FaceId
Extend destroy/add-nexthop/register subcommands to allow FaceUri in place of FaceId:
nfdc destroy FaceId-or-FaceUri nfdc add-nexthop [-c cost] /prefix FaceId-or-FaceUri nfdc register [-I] [-C] [-c cost] /prefix FaceId-or-FaceUri
Only FaceUris acceptable by faces/create command are allowed.
When FaceUri is specified in place of FaceId, faces/create command is called to retrieve the FaceId (or create a new face if it does not exist).
"add" subcommand is deleted because it becomes a duplicate of "add-nexthop" command.
"add-nexthop" syntax is slightly modified to make cost an optional named argument, instead of an optional positional argument.
#2 Updated by Syed Amin over 5 years ago
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.
#3 Updated by Alex Afanasyev over 5 years ago
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).
#5 Updated by Junxiao Shi over 5 years ago
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.
#6 Updated by Syed Amin over 5 years ago
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.
#10 Updated by Syed Amin over 5 years ago
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.
#17 Updated by Syed Amin over 5 years ago
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.
#18 Updated by Junxiao Shi over 5 years ago
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.
#19 Updated by Syed Amin over 5 years ago
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.
#21 Updated by Beichuan Zhang over 5 years ago
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.