NFD

I have slightly modified the table definition and added a function for returning table's elements(regionNames) for now.

there should be a mechanism for clients to retrieve Region Name(s) of local router which the client is connected to

What's the use case of this mechanism?
Having a region name does not mean it's routable. Routable prefixes are offered in #3145 and they are more useful to applications.

I have slightly modified the table definition and added a function for returning table's elements(regionNames) for now.

This is totally unnecessary because NetworkRegionTable publicly inherits from std::set<Name>, so that a caller can enumerate region names using std::set APIs.

Junxiao Shi wrote:

What's the use case of this mechanism?
Having a region name does not mean it's routable. Routable prefixes are offered in #3145 and they are more useful to applications.

DelegationNames in Link objects are supposed to be routable in internetwork environments(including DFZ). If not, there is no use for Links. So, if a mobile node relocates into a new network, mobile node applications or mobile nfd should first be aware of the fact that the node has relocated into a new network. Secondly, they should somehow learn about which delegationNames they can use for their new Link object.
Actually at the end I'm proposing a protocol for mobility support, which I have done some experiments on it partially.

Junxiao Shi wrote:

This is totally unnecessary because NetworkRegionTable publicly inherits from std::set, so that a caller can enumerate region names using std::set APIs.

This may be true. But with this argument, then you would not need functions for NodeContainer (e.g. in globalRoutingHelper) when you have such for Ptr, because a caller can already go with multiple Ptr ones.

if a mobile node relocates into a new network, mobile node applications or mobile nfd should first be aware of the fact that the node has relocated into a new network. Secondly, they should somehow learn about which delegationNames they can use for their new Link object.

I agree with this use case. However, I disagree with rushing the implementation until the high-level question below is resolved.

There's still a missing piece: The NetworkRegionTable could contain a longer prefix than the network domain in which a globally-unroutable name is announced; if an application creates a Link object with a name from local NetworkRegionTable, it can result in suboptimal network operations.
For example, /net/ndnsim prefix is announced within UCLA CS dept, and it's served by two producers. The NetworkRegionTable on one of the producers is configured as /edu/ucla/cs/ndnsim-server-1 and the other as /edu/ucla/cs/ndnsim-server-2. Ideally, the Link object should be created with /edu/ucla as delegation name, and the UCLA-CS router can load balance between the two servers; if the producer creates a Link object with the prefix /edu/ucla/cs/ndnsim-server-1 from the NetworkRegionTable, it would render the other producer useless.
One proposal would be to configure both producers' NetworkRegionTable with /edu/ucla/cs. However, if one of the machine also needs to serve some other content that cannot be announced into UCLA CS dept, the other Link object would need to point to one specific machine, which becomes impossible because there isn't a region for that.

Junxiao Shi wrote:

There's still a missing piece: The NetworkRegionTable could contain a longer prefix than the network domain in which a globally-unroutable name is announced; if an application creates a Link object with a name from local NetworkRegionTable, it can result in suboptimal network operations.
For example, /net/ndnsim prefix is announced within UCLA CS dept, and it's served by two producers. The NetworkRegionTable on one of the producers is configured as /edu/ucla/cs/ndnsim-server-1 and the other as /edu/ucla/cs/ndnsim-server-2. Ideally, the Link object should be created with /edu/ucla as delegation name, and the UCLA-CS router can load balance between the two servers; if the producer creates a Link object with the prefix /edu/ucla/cs/ndnsim-server-1 from the NetworkRegionTable, it would render the other producer useless.
One proposal would be to configure both producers' NetworkRegionTable with /edu/ucla/cs. However, if one of the machine also needs to serve some other content that cannot be announced into UCLA CS dept, the other Link object would need to point to one specific machine, which becomes impossible because there isn't a region for that.

Actually I'm not sure If I understood the problem quite clearly. When you talk about local NRT, I'm a bit confused. Each node can have NRT as part of its nfd. But what's the use of configuring NRT for an individual content producer node?

While I agree with ignoring the API extension and repeat the above, simultaneously:
So, are nodes supposed to publish NRT dataset - which I assume only includes a set of ndn::name - among other sets of data? Actually I don't think NRT status has things to do with FIB or Face managers. I think it will be something more like Discover local hub prefix:
http://named-data.net/doc/NFD/current/misc/local-prefix-discovery.html#local-prefix-discovery

Reply to note-7:

I'm unsure about the usefulness of a NetworkRegionTable dataset due to the missing piece identified in note-5.
The relation between NetworkRegion configuration and routable prefixes dataset (#3145) needs to be discussed.

Reply to note-8:

I agree with the need for second one to be discussed.

Reply to note-5:

I believe lookup for delegationNames should be based on exact match so that we can have different scales in Link usage.
For the first piece of yours, I think you are looking for load balancing which is not the goal of Link objects. selectedDelegation is there to prefer/select one delegationName to another. If there needs to be load balancing, owners of NRTs are responsible for making it possible.
Sorry. I didn't understand the problem with "However..." part. Could you elaborate more?