Bug #4332
closed"nfdc route add" doesn't create face
100%
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
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.
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.
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.
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.
Updated by Davide Pesavento about 7 years ago
I found the discussion: http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2017-January/002223.html
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.
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.
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.
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.
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.
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 usednfdc 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.
Updated by Davide Pesavento almost 7 years ago
- Target version changed from v0.6 to v0.7
Updated by Eric Newberry over 4 years ago
- Status changed from New to In Progress
- Target version set to 22.02
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?
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.
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.
Updated by Davide Pesavento over 4 years ago
Alex Afanasyev wrote:
To support face flags,
nfdc route add
should support the same optional flags asnfdc 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.
Updated by Eric Newberry over 4 years ago
- Status changed from In Progress to Code review
- % Done changed from 0 to 100
Updated by Eric Newberry over 4 years ago
- Status changed from Code review to Closed