Project

General

Profile

Task #1515

nfdc allows FaceUri in place of FaceId

Added by Junxiao Shi over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Tools
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
3.00 h

Description

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.


Related issues

Related to NFD - Task #1722: FaceMgmt: query operationClosed

Blocked by NFD - Task #1416: nfdc register/unregister subcommandsClosed2014-03-27

History

#1 Updated by Junxiao Shi over 5 years ago

  • Blocked by Task #1416: nfdc register/unregister subcommands added

#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).

#4 Updated by Syed Amin over 5 years ago

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.

#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.

#7 Updated by Junxiao Shi over 5 years ago

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.

#8 Updated by Lan Wang over 5 years ago

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.

#9 Updated by Junxiao Shi over 5 years ago

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

#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.

#11 Updated by Junxiao Shi over 5 years ago

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.

#12 Updated by Beichuan Zhang over 5 years ago

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

#13 Updated by Junxiao Shi over 5 years ago

  • Description updated (diff)

20140423 conference call decides that remove-nexthop/unregister commands allow only FaceId.

In the future, remove-nexthop/unregister commands may accept FaceUri when protocol supports querying FaceId by FaceUri.

#14 Updated by Syed Amin over 5 years ago

  • % Done changed from 0 to 60

May be we don't need Task #1416 anymore, I can submit one commit with refs to both tasks?

#15 Updated by Junxiao Shi over 5 years ago

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

#16 Updated by Syed Amin over 5 years ago

  • Status changed from New to Code review
  • % Done changed from 60 to 90

#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.

#20 Updated by Junxiao Shi over 5 years ago

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.

#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.

#22 Updated by Alex Afanasyev over 5 years ago

  • Status changed from Code review to Closed
  • % Done changed from 90 to 100

#23 Updated by Alex Afanasyev over 5 years ago

  • Related to Task #1722: FaceMgmt: query operation added

Also available in: Atom PDF