[Nfd-dev] nfdc implicit face creation problems

Alex Afanasyev aa at CS.UCLA.EDU
Tue Jan 31 10:22:36 PST 2017


> On Jan 31, 2017, at 10:15 AM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:
> 
> On Tue, Jan 31, 2017 at 12:59 PM, Alex Afanasyev <aa at cs.ucla.edu> wrote:
>> 
>> On Jan 31, 2017, at 9:53 AM, Davide Pesavento <davide.pesavento at lip6.fr>
>> wrote:
>> 
>> On Tue, Jan 31, 2017, 12:46 PM Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>>> 
>>> 
>>> I propose dropping implicit face creation feature during nfdc refactoring:
>>> (1) nfdc face create is the only subcommand that can create a face.
>>> (2) nfdc route add and nfdc route remove (replacements of nfdc register
>>> and nfdc unregister) do not implicitly create faces. They can accept either
>>> FaceId or FaceUri. When specifying FaceUri, we query the existing faces
>>> whose RemoteUri matches the specified FaceUri. If one exact match is found,
>>> that face is used. If no face with that RemoteUri is found, an error message
>>> is printed. If two or more matches are found, an error message is printed
>>> with the list of matched faces, and the operator can re-run the command with
>>> one of the FaceIds from that list.
>>> 
>>> This is consistent with iproute2 programs, where you must explicitly
>>> create an interface before using it in IP routing tables.
>> 
>> 
>> I support this proposal.
>> 
>> 
>> I do not support this proposal.  This creates inter-commmand dependency for
>> basic operations as registering prefix to a new face.  We should not create
>> more obstacles for users for the sake of having consistent interface with IP
>> tools.
>> 
> 
> Junxiao listed 4 problems with the current approach. Consistency with
> iproute2 is not one of them. It would be an additional bonus (assuming
> we consider interface == face, which is arguable), but it's definitely
> not the main reason behind this proposal.
> 
> Can you elaborate on the "inter-command dependency"? I'm not sure what
> you mean and how it is a problem.

How would you register a route to a new face?  For what I understand the proposal is:

- nfdc face create udp:/bla
then look what the random face id is returned, remember it

- nfdc register the-remembered-face-id

I read the list of issues, but do not see them as problems.  Yes, there is no guarantee it going to work.  The helper method that accept faceUri is helper methods.  Bad analogy, bug with git you're probably using many helpers, instead of calling individual low-level commands (receive-pack, upload-pack, etc.).

---
Alex


More information about the Nfd-dev mailing list