NFD

This issue is not blocked by #2107. Despite code location is within mgmt/, configuration file processing procedures is not expected to be touched by #2107.

1. I also prefer not including %C1.Router in the configuration. However, it may be good to include a comment that the final router name will include this marker between site and router name segments to avoid any surprises to the operator.

2. Monitoring the ForwarderStatus seems to be the straightforward solution to learn the changed name. Any other lighter weight solution?

Reply to note-6 and note-7:

/ndn /edu/memphis /titan should be represented as PartialNames, not absolute Name. Therefore, drop the '/' in front.

It's necessary to add comments to describe the semantics of network, site, and router.

I agree that "%C1.Router" shouldn't appear in the configuration.

During a configuration reload, NLSR will not be disconnected.
NLSR shouldn't poll the ForwarderStatus dataset, because it's unnecessary overload most of the time, and has a delay when the change happens.

Instead, we could require the caller to send a reload signal to NLSR as well, so NLSR can reload both its own configuration file and the ForwarderStatus dataset; if the caller does not signal NLSR, the change in RouterName does not take effect in routing.

Junxiao Shi wrote:

Reply to note-6 and note-7:

/ndn /edu/memphis /titan should be represented as PartialNames, not absolute Name. Therefore, drop the '/' in front.
It's necessary to add comments to describe the semantics of network, site, and router.
I agree that "%C1.Router" shouldn't appear in the configuration.

Is the following change to the general section in "nfd.conf.sample.in" a correct starting point for implementation? The exact wording of the comments can be reviewed on Gerrit.

; The general section contains settings of nfd process.
general
{
  ; Specify a user and/or group for NFD to drop privileges to
  ; when not performing privileged tasks. NFD does not drop
  ; privileges by default.

  ; user ndn-user
  ; group ndn-user

  ; The router_name section specifies the name components used
  ; to build this router's name. The router name is constructed
  ; using the configuration options in the following manner:
  ;   /<network>/<site>/<%C1.Router>/<router>

  ; router_name
  ; {
  ;   network ndn ; the network to which this router belongs
  ;   site    edu/site ; the site to which this router belongs
  ;   router  router/name ; name used to uniquely identify this router under the site
  ; }
}

Junxiao Shi wrote:

During a configuration reload, NLSR will not be disconnected.
NLSR shouldn't poll the ForwarderStatus dataset, because it's unnecessary overload most of the time, and has a delay when the change happens.

Instead, we could require the caller to send a reload signal to NLSR as well, so NLSR can reload both its own configuration file and the ForwarderStatus dataset; if the caller does not signal NLSR, the change in RouterName does not take effect in routing.

The caller will need to explicitly trigger an NLSR reload, so this is not something that needs to be implemented in this task, right?

I agree to both points in note-9.

http://gerrit.named-data.net/#/c/2243/1 implements configuration options, but remembers them in a static variable. I would like to avoid introduction of static elements, as it would impede support in ndnSIM.

I think we need some kind of an instance of a general manager that should remember any necessary state. We didn't need it before, but may need it now.

Reply to note-12:

I agree with this idea but disagree with requiring it now.
It should be separate issue and arranged after #2107 and #3029, because it has some interaction with ForwarderStatus.

A simple RouterName is needed now for mobility with Link.

I am not convienced that this has blocking on refactored management, but I agree to defer non-static general state recording to further commit. However, we should do it before next release (either minor or major).

This is an easy fix, just want to be clear which is preferred before I start implementation:

If I mimic the current behavior, each time RouterName::getName is called, the router's prefix will be constructed and assigned to a private member variable which will be returned. If the public member variables (network, site, router) are modified, the change will be reflected by RouterName::getName().

An alternative is to only construct the router's prefix after the configuration file is loaded and just return the reference in RouterName::getName(). This reduces the overhead of building the prefix, but if the public member variables are modified, RouterName::getName() will not reflect the changes.

Another alternative is to make RouterName's public member variables (network, site, router) private, and only build the router's prefix when the setters are used.

Answer to note-20:

• RouterName type should expose three PartialNames and a complete Name; all of them should be declared as const Name so they cannot be changed out of constructor.
• RouterName constructor should take three PartialNames, assign them to member fields, and build the complete Name.

In that case, should the RouterName static variable be moved to global scope and be made a unique_ptr?

Reply to note-22:

This is an implementation detail. Implementer should make this decision.

According to #3000 note-20, mobility feature no longer uses RouterName.

Should we revert this feature, and keep RouterName in NLSR configuration file?

If reverting, #3027 #3028 #3029 #3030 #3025 will be reverted or abandoned as well.

Revert Change: http://gerrit.named-data.net/2357