Project

General

Profile

Actions

Bug #4332

closed

"nfdc route add" doesn't create face

Added by Alex Afanasyev about 7 years ago. Updated over 4 years ago.

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

100%

Estimated time:

Description

On my macOS 10.13:

nfdc route add / udp4://1.1.1.1:6363

expected to create udp4://1.1.1.1:6363 face and register route towards the face

Actual:

✔  17:36 /usr/local/etc/ndn $ nfdc route add / udp4://1.1.1.1:6363
Face not found
Actions #1

Updated by Alex Afanasyev about 7 years ago

  • Tracker changed from Task to Bug
Actions #2

Updated by Junxiao Shi about 7 years ago

  • Status changed from New to Rejected

This behavior is by design. The operator must first execute nfdc face create to create the face, then reference an existing face in nfdc route add (you may use remote FaceUri if it's unique, so you don't have to record the FaceId). See #3229-6.

Actions #3

Updated by Alex Afanasyev about 7 years ago

  • Status changed from Rejected to New

What? https://redmine.named-data.net/issues/3866 is referred but there is no motivation recorded. I remember the conversation, but that was about implicit creation during "route show/remove" commands, not add.

I declare that the current "nfdc route add" command is unusable.

I also can state that the current interface is very unfriendly. I have no clue now to get help for specific subcommand and there is no help message.

Actions #4

Updated by Davide Pesavento about 7 years ago

  • Category changed from Management to Tools

Alex Afanasyev wrote:

I declare that the current "nfdc route add" command is unusable.

That seems a bit extreme, why do you say so? We discussed about removing the implicit face creation and there was no objection.

I also can state that the current interface is very unfriendly. I have no clue now to get help for specific subcommand and there is no help message.

I agree that the messages could be more user-friendly.

Actions #5

Updated by Alex Afanasyev about 7 years ago

2017-10-09 call decided to extend nfdc route add to support implicit creation of faces. To support face flags, nfdc route add should support the same optional flags as nfdc face create and in future we need to make sure that optional flags are non-overlapping.

Actions #7

Updated by Davide Pesavento about 7 years ago

  • Start date deleted (10/06/2017)

In any case, there should probably be an option to prevent the automatic creation of the face, i.e. bail out with an error if the FaceUri doesn't match any existing face.

Actions #8

Updated by Junxiao Shi about 7 years ago

Did the conference call consider the arguments given in note-6? If not, this matter should be re-discussed.

there should probably be an option to prevent the automatic creation of the face

Not creating a face should be the default. Creating a face may be behind an argument allow-face-creation. All face creation arguments need to be named and not positional.

Actions #9

Updated by Alex Afanasyev about 7 years ago

Davide Pesavento wrote:

I found the discussion: http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2017-January/002223.html

Now I remember the conversation and my position regarding this issue was the same. I was told (may be I misunderstood, though) that the behavior with implicit face creation would not change for "register" stage. Therefore, I agreed in the end. However, that agreement was under the understanding that users are not introduced a new burden to run two commands or "remember" to type additional command line options.

Actions #10

Updated by Alex Afanasyev about 7 years ago

Junxiao Shi wrote:

Not creating a face should be the default. Creating a face may be behind an argument allow-face-creation. All face creation arguments need to be named and not positional.

I disagree with this. My proposal is exactly the opposite. The default: implicit creation of the face (for nfd route add only). The flag disable-face-create to disable implicit face creation capability when FaceUri is specified. There is no implicit creation when face Id is specified.

Actions #11

Updated by Teng Liang almost 7 years ago

What's the status of this issue?

Here is my personal experience on this:
I tried the new commands to connect two NFDs. Specifically, I used the first command nfdc face create udp4://192.168.2.3:6363 to create a face (FaceId = 263), then I used nfdc route add /test 263 to add a route. Note that I tried several times and figured out to use the FaceId when creating a route. Compared to the previous command and tutorial, the new commands are less user-friendly. As a user, I would prefer the deprecated command.

Actions #12

Updated by Junxiao Shi almost 7 years ago

I used the first command nfdc face create udp4://192.168.2.3:6363 to create a face (FaceId = 263), then I used nfdc route add /test 263 to add a route.

The second command could also be nfdc route add /test udp4://192.168.2.3:6363, if that remote FaceUri is unique. It’s just that the first command becomes mandatory.

Actions #13

Updated by Davide Pesavento almost 7 years ago

  • Target version changed from v0.6 to v0.7
Actions #14

Updated by Davide Pesavento about 5 years ago

  • Target version deleted (v0.7)
Actions #15

Updated by Anonymous about 5 years ago

I want to upvote this bugreport.

Actions #16

Updated by Eric Newberry over 4 years ago

  • Assignee set to Eric Newberry
Actions #17

Updated by Eric Newberry over 4 years ago

  • Status changed from New to In Progress
  • Target version set to 22.02
Actions #18

Updated by Eric Newberry over 4 years ago

What should the behavior be if the face already exists but face options are specified to route add? Should the options be ignored or should the face be updated to use the new options?

Actions #19

Updated by Davide Pesavento over 4 years ago

Eric Newberry wrote:

What should the behavior be if the face already exists but face options are specified to route add? Should the options be ignored or should the face be updated to use the new options?

What options? nfdc route add doesn't support any face options as far as I know.

Actions #20

Updated by Eric Newberry over 4 years ago

Davide Pesavento wrote:

Eric Newberry wrote:

What should the behavior be if the face already exists but face options are specified to route add? Should the options be ignored or should the face be updated to use the new options?

What options? nfdc route add doesn't support any face options as far as I know.

See note 5 above.

Actions #21

Updated by Davide Pesavento over 4 years ago

Alex Afanasyev wrote:

To support face flags, nfdc route add should support the same optional flags as nfdc face create and in future we need to make sure that optional flags are non-overlapping.

Oh, I would actually be slightly against that. It could become quite messy to support (and document!) all face settings in both places. Moreover, a "face-creating" route add is supposed to be a shortcut, in my opinion it doesn't have to support all possible face flags and options, just the local/remote FaceUris (and maybe persistency) should be enough to cover the vast majority of use cases. More advanced settings can still be changed using the face create + route add combination.

Eventually we should introduce a nfdc face set (exact name TBD) that allows changing the parameters of an existing face, essentially equivalent to the "update" part of face create, except that it fails if the face doesn't already exist. This can already be done with face create today, but "create" here is completely counterintuitive when the user knows that the face already exists. In fact, I'm starting to think that giving also "update" semantics to face create was a mistake.

Actions #22

Updated by Eric Newberry over 4 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 0 to 100
Actions #23

Updated by Eric Newberry over 4 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF