NFD

http://gerrit.named-data.net/2477 implements a temporary workaround, where faces/enable-local-control enables all local fields in GenericLinkService, and faces/disable-local-control disables all local fields in GenericLinkService.

Was anyone already planning to work on this?

I discussed with Eric on Jul 08.

The plan is:

• eliminate faces/enable-local-control and faces/disable-local-control commands
• extend faces/update command to allow a "local fields enabled" property
• there would be no protocol limitation on changing this property for other faces (but validator can restrict that)

Alex approves note-5 idea 20160719 call.

For solutions B and C, where is the Flags field documented? It's mentioned on the ControlCommand page, but I can't find any specific documentation.

If we have a chance to make this feature more intuitive and logical, we should. Therefore, I think solution D might be the best.

For solutions B and C, where is the Flags field documented?

ControlParameters struct covers every field that existing commands want to use, but the semantics of each field is up to the definition of each command.

RibMgmt rib/register uses Flags field for route inheritance flags.
I don't know about any other usage.

If we have a chance to make this feature more intuitive and logical, we should. Therefore, I think solution D might be the best.

Yes, solution D is my eventual goal.

The concern is: we just spent the entire 2015 on "management refactoring" #2107; if we change the protocol, another refactoring is coming.
It affects ControlCommands only and requires small changes in Dispatcher, but converting the large number of test cases is much more work.

I asked Beichuan about this on 20160803. His opinion is that we can proceed with the protocol change only if it won't take a whole year.

Can Eric estimate how much time it would take to implement the change? Give two estimates on "FaceMgmt only" and "all management modules".

There is currently a mismatch between the fields in ControlParameters and FaceStatus. In order to use FaceStatus for any management operations, fields from ControlParameters will need to be added to its design in ndn-cxx. These fields are Name, Origin, Cost, Flags, Strategy, and LocalFields (from #3226). Adding these fields to FaceStatus should take approximately 1 to 2 hours. Modifying and ensuring the correctness of the FaceStatus test case (ManagementNfdFaceStatus) could take up to 2 hours. These steps will be required for both options.

In order to replace ControlParameters with FaceStatus only in the Face Manager, ControlCommand, Controller, Dispatcher, DummyClientFace, and Face::Impl in ndn-cxx and ManagerBase and NfdManagerBase in NFD will need to be changed to accept both ControlParameters and FaceStatus (in the form of a template). In addition, checks should be created so that the FIB Manager, the Strategy Choice Manager, and the Forwarder Status Manager will not be provided with a FaceStatus and that the Face Manager will not be provided with a ControlParameters. This could take up to 8 hours. The Face Manager itself will need to be modified to use FaceStatus, which should take 2 to 3 hours. The ndn-autoconfig and nfdc tools will also need to be modified to use the appropriate blocks for each manager. These modifications and testing their correctness could take up to 5 hours. In addition, correcting unit tests and adding cases to cover the new functionality could take up to 6 hours.

In order to replace ControlParameters with FaceStatus in the entirety of management, all of the classes and tools specified in the previous paragraph will need to modified. However, instead of using templates, all instances of ControlParameters will be replaced with FaceStatus, which is more straightforward. Therefore, I would estimate that those steps would take roughly half the time in the second option. In addition, RegisteredPrefix in ndn-cxx and FibManager and StrategyChoiceManager in NFD will need to be modified to use FaceStatus. I estimate that this would take 1 hour. I estimate that modifying their test cases would take 3 hours. In addition, AutoPrefixPropagator, FibUpdater, Rib, and RibManager will need to modified as well, taking 3 to 4 hours. Various associated test cases will need to be updated, taking around 4 hours. MulticastDiscovery in nfd-autoconfig and nfd-autoreg will need to modified to use FaceStatus, taking up to 2 hours.

From the above estimates, the total amount of time to only modify FaceMgmt would be up to 26 hours. The time to refactor all of management would be up to 24 hours. These figures are arbitrary best-guesses based upon my past coding work in ndn-cxx and NFD. Of course, there will almost certainly be unexpected or overlooked changes that must be made, so the above figures should be multiplied by 1.5x to 2x for a more accurate upper bound.

Files that I believe would need to be modified in option 1:

• (ndn-cxx) src/detail/face-impl.hpp
• (ndn-cxx) src/management/nfd-control-command.cpp
• (ndn-cxx) src/management/nfd-control-command.hpp
• (ndn-cxx) src/management/nfd-controller.cpp
• (ndn-cxx) src/management/nfd-controller.hpp
• (ndn-cxx) src/management/nfd-face-status.cpp
• (ndn-cxx) src/management/nfd-face-status.hpp
• (ndn-cxx) src/mgmt/dispatcher.cpp
• (ndn-cxx) src/mgmt/dispatcher.hpp
• (ndn-cxx) src/util/dummy-client-face.cpp
• (ndn-cxx) tests/unit-tests/management/nfd-control-command.t.cpp
• (ndn-cxx) tests/unit-tests/management/nfd-controller.t.cpp
• (ndn-cxx) tests/unit-tests/management/nfd-face-status.t.cpp
• (ndn-cxx) tests/unit-tests/mgmt/dispatcher.t.cpp
• (NFD) core/manager-base.cpp
• (NFD) core/manager-base.hpp
• (NFD) daemon/mgmt/face-manager.cpp
• (NFD) daemon/mgmt/face-manager.hpp
• (NFD) daemon/mgmt/nfd-manager-base.cpp
• (NFD) daemon/mgmt/nfd-manager-base.hpp
• (NFD) tests/core/manager-base.t.cpp
• (NFD) tests/daemon/mgmt/face-manager.t.cpp
• (NFD) tests/daemon/mgmt/nfd-manager-base.t.cpp
• (NFD) tests/manager-common-fixture.cpp
• (NFD) tests/manager-common-fixture.hpp
• (NFD) tools/ndn-autoconfig/base.cpp
• (NFD) tools/ndn-autoconfig/base.hpp
• (NFD) tools/nfdc.cpp
• (NFD) tools/nfdc.hpp

Files for option 2:

• All files from option 1
• (ndn-cxx) src/detail/registered-prefix.hpp
• (NFD) daemon/mgmt/fib-manager.cpp
• (NFD) daemon/mgmt/fib-manager.hpp
• (NFD) daemon/mgmt/strategy-choice-manager.cpp
• (NFD) daemon/mgmt/strategy-choice-manager.hpp
• (NFD) rib/auto-prefix-propagator.cpp
• (NFD) rib/auto-prefix-propagator.hpp
• (NFD) rib/fib-updater.cpp
• (NFD) rib/rib.hpp
• (NFD) rib/rib-manager.cpp
• (NFD) rib/rib-manager.hpp
• (NFD) tests/daemon/mgmt/fib-manager.t.cpp
• (NFD) tests/daemon/mgmt/strategy-choice-manager.t.cpp
• (NFD) tests/rib/auto-prefix-propagator.t.cpp
• (NFD) tests/rib/rib-manager.t.cpp
• (NFD) tests/rib/rib-status-publisher-common.hpp
• (NFD) tools/ndn-autoconfig/multicast-discovery.cpp
• (NFD) tools/nfd-autoreg.cpp

note-11 is an impressive analysis.

In order to use FaceStatus for any management operations
instead of using templates, all instances of ControlParameters will be replaced with FaceStatus

These two points are wrong. FaceStatus can only be used with FaceMgmt. Other management module should use other structs, such as ndn::nfd::StrategyChoice for StrategyChoice commands, so you can't avoid templates.

Then I realize this is where the complexity comes from: we don't have a suitable struct for FibMgmt and RibMgmt commands.

fib/add-nexthop, for example, needs {name prefix, nexthop face, cost}, but the struct in FIB dataset ndn::nfd::FibEntry contains all nexthop records associated with a name prefix.
Although we could use ndn::nfd::FibEntry for fib/add-nexthop command, there's additional complexity: do we want to restrict to only one nexthop record, or do we want to support adding multiple nexthops together?

Similarly, if we use ndn::nfd::FibEntry in fib/remove-nexthop command, "cost" field is not needed in the request, and this requires modification in the encoding/decoding procedures.

Based on this reasoning and the 26-hour estimate given in note-11, I think changing parameter types would take longer than 26 hours, and thus we should not change FaceMgmt commands parameter type to FaceStatus.

On the other side, we can consider changing the response payload to FaceStatus to represent the current state of a face and better support nfdc, but this should be left for a separate issue.

If solution D is not pursued, I would argue for solution C. It seems to be the most logical and efficient solution, as the Flag and Mask fields could be used for a variety of other face options in the future.

20160809 call agrees with pursue Solution C. I'll update spec accordingly.

The spec at the specified wiki pages looks good.

From faces/update in FaceMgmt:

If all optional property fields are omitted or Mask is specified as zero, this command does nothing, but is still considered successful.

This statement is confusing me a bit. There are other static property fields besides Flags and Mask. However, from what I understand from this statement, if FacePersistency is included, but Mask is still set to 0, the face persistency will not be updated. Is this correct? If not, this wording should be changed to state the intended behavior.

note-21 problem is corrected in FaceMgmt r53.

From "Face Status Change Notification" in FaceMgmt:

FaceEventKind indicates the kind of event. Its possible values are:

• 1: face is created
• 2: face is destroyed

Should these notifications also be sent when the static properties of the face are updated? If so, a third type of event should be added, indicating "face is updated", "static properties are updated", or something similar.

Reply to note-23:

Not at the moment. If there's a use case, I can extend the protocol in a separate issue.