NLSR

The first step should be updating the wiki page with the configuration file defined here: http://gerrit.named-data.net/#/c/759/2/nlsr.conf

Is there a reason why network, site-name, router-name, and some others represented as sections? If it is just one parameter, then it should be just parameters...

there was reason previously for security module of NLSR to check the hierarchy of keys and router name. But We are not using that hierarchy anymore. Yingdi will work on the new security module for NLSR.

So we can merge all this three to one

I think what Alex mentioned is whether section is necessary. If a section contains only one property, then INFO allows you to specify the configuration as:

router
{
  network /ndn
  site /memphis.edu/cs
  router /pollux
}

For the hello section, I guess there is only one interest-retry section, right? If so, interest-retry section is not necessary. You can directly specify retry number and interval in hello section. I would also recommend you to move these two properties to the beginning and enforce strict order. Such as:

hello
{
  retrials 3
  interval 10
  neighbor
  {
    ...
  }
  neighbor
  {
    ...
  }
  ...
}

Also, do we have any other type of neighbor? If not, I would suggest using neighbor rather than ndnneighbor.

For synchronization section, please remove unnecessary sections as well. Besides that, I wonder whether we need to specify the sync prefix explicitly? I think /ndn is the network name, and /nlsr/sync is fixed by the application, we can easily determine the sync prefix from the information specified in router section. Moreover, I am not clear about lsa-refresh-time, I mean, why it is a part of synchronization configuration?

For hyperbolic section, I would suggest to define it as:

hyperbolic
{
  state  off ; or dryrun
  radius 123.456
  angle  1.45
}

For fib section, why tunnel is a part of FIB configuration? Also there are some unnecessary sections.

For advertising section, why the prefix is different from the router's prefix? If they should be the same, then why this section is needed?

Agreed on router, Hello and hyperbolic section

No other type of neighbor so it can also be just neighbor.

For advertising section:
Prefixes are different from router prefix as in this section router advertises all the name prefixes
hosted by this router ( In other words all other router should forward interest in those name prefixes
to this router)

For sync-prefix the example is /ndn/nlsr/sync. Yes in the example /ndn is the network name but not
necessarily the sync prefix have to contain network name. It can just be /routing/nlsr/sync.

What are the unnecessary sections of FIB?

tunnel type is there to give admin flexibility of tunnel creation of their choice.
Max-face-per-prefix is to restrict the number of faces added by NLSR.

I still did not get the usage of advertising, could you give some examples here?

Is there any benefit of using a sync prefix that is independent of the network?

For tunnel, I think it is related to face management rather than FIB. Please correct me if I am wrong.

My understanding is that advertising specified prefixes that this router "exports". The current definition should also be simplified to

advertising
{
    pretix /ndn/edu/memphis/cs/netlab ; name in ndn URI format
    prefix /ndn/edu/...
    prefix /ndn/edu/...
}

Yes Alex is right about the advertising

NLSR will create face and register neighbor's name, sync-prefix to that face id. So tunnel-type is way of giving some freedom to the system admin.

Why should we make sync-prefix dependent on network prefix?

I'm actually also confused with the tunnel. I don't see the necessity for it. There is already configuration of "tunnels" in neighbors section. You just extend it to include necessary information about which face the neighbor is using. The configuration should not depend on assumption that we are using IP-based faces. My suggestion is to define not host, but NFD's "FaceUri", which would include everyting that is needed to create/use the face and would not restrict on the use of IP-based faces (one will be able to configure EthernetFace).

yes we can name it to the FaceUri in neighbor section.
Then system admin need to create the face and configure
configuration file according to that.

But only one problem with FaceUr. As far as I know
using FaceUri we can not unregister any prefix. If that is
solved we can change this.

Then tunnel-type is not necessary.

Right not we can use face-id instead of faceUri if we can not unregister by faceUri.

And we can remove the tunnel-type

Just a few clarifications.

1. The tunnel type is for what kind of tunnel the application traffic will be carried in. Basically, when we insert a FIB entry for a prefix, what tunnel will the FIB entry use? The neighbor section is to specify how the routing protocol connects to the neighbor. If we put that in the neighbor's specification, then all the prefixes have to use that tunnel. My question is will all the application traffic be carried in the same tunnel as the routing protocol traffic? For example, the routing traffic may be carried in a UDP tunnel, but some applications may want to use a TCP tunnel for the traffic. Of course, right now if we put the tunnel type separate from the prefix section, then all the prefixes have to use one tunnel type. So ideally, for the scenario I have in mind, the tunnel type should be per-prefix.

2. The sync section is for synchronizing routing data. The LSA refresh period is there right now because it is also related to keeping the routing data in sync, although it's not related to ChronoSync.

3. I agree with Yingdi that there is no need to specify the sync prefix. It can be just fixed based on the network prefix, i.e., //nlsr/sync.

Lan Wang wrote:

Just a few clarifications.

1. The tunnel type is for what kind of tunnel the application traffic will be carried in. Basically, when we insert a FIB entry for a prefix, what tunnel will the FIB entry use? The neighbor section is to specify how the routing protocol connects to the neighbor. If we put that in the neighbor's specification, then all the prefixes have to use that tunnel. My question is will all the application traffic be carried in the same tunnel as the routing protocol traffic? For example, the routing traffic may be carried in a UDP tunnel, but some applications may want to use a TCP tunnel for the traffic. Of course, right now if we put the tunnel type separate from the prefix section, then all the prefixes have to use one tunnel type. So ideally, for the scenario I have in mind, the tunnel type should be per-prefix.

2. The sync section is for synchronizing routing data. The LSA refresh period is there right now because it is also related to keeping the routing data in sync, although it's not related to ChronoSync.

3. I agree with Yingdi that there is no need to specify the sync prefix. It can be just fixed based on the network prefix, i.e., /network/nlsr/sync.

Tunnel type is necessary only when creating face.

For name registration either faceId or faceUri is necessary.
So how per name prefix based tunnel type is useful for registering
that prefix? NLSR usually register prefixes to some existing
faces.

I'm really confused. There should not be any concept of "tunnel" in the first place. There is only connections to neighbors and it happened to be the case that we are currently using tunnels. As soon as Face/tunnel created, it is used for all communications towards this neighbor. There is absolutely no valid reason for me to create "other" tunnel for some "other" purpose. TCP faces are only for cases when UDP is literally not working.

If NLSR combines this neighbor management / Face-tunnel management, there should not be separate section. It just have to do something to create Face if it doesn't exist, or just use it if it is already exists.

I don't get at all "number prefixes per tunnel". There is no such a concept for me...

So NLSR configuration file should only take faceId or faceUri, right? And thats also in neighbor section.

Hoque: for the unregister problem for FaceURI, do you get a FaceID back when you register using FaceURI? If so, then you can use the FaceID for unregistering and other needs.

Alex: for the tunnels, I was thinking more about people doing experimentation on the testbed. Some applications may want to try their applications under different network environment. In any case, I think it's probably unnecessary. Putting the tunnel type in the neighbor section is fine.

Why not admin just configure faceId? Is configuring faceUri has a smaller probability of making mistakes then configuring faceId?

The number of configuring faceId is not that high, it is the number of neighbor.

IMHO, faceId may change, but faceURI is much more static.

I see, why can not we unregister with faceUri now?

It's temporary problem due to the unavailability of a way to check if a face exists or not. For the complete discussion, see http://redmine.named-data.net/issues/1515#change-2441

Please have a look at the updated nlsr.conf

http://redmine.named-data.net/projects/nlsr/wiki/Configuration_File_Format

Renamed synchronization section to general and added one extra command for log-level.

Check whether we all can agree on it.

Some small suggestions:

• move general section to be the first one
• update comment for "router"
• i would rename "retrials" to "retries"
• i would move "neighbor" to a separate neighbors section. It just defines who neighbors are, and don't think it is specific to "hello"
• still don't understand what "fib" section is and what "max-faces-per-prefix" is... If it is necessary, then it should go to general section.
• shall advertising be moved inside "router"?

Updated the configuration file as first four suggestions.

We are keeping the FIB section thinking about future scope. In future we may have better
multipath calculation and for comparing result of computation other configuration parameter
can be added.

max-faces-per-prefix is a configuration parameter to limit the number of faces per name-prefix when registering
in NFD's fib. By default NLSR registers a name prefix for all calculated faces. But
by this parameter one can restrict the number of faces per prefix.

Advertising should not go to the router section. Purpose of this section is to advertise to other routers in the network

Just a comment about the organization of the config file. I wonder why "hello" is not in the general section but "lsa-refresh-time" is put into the general section. Do we use hello protocols with different settings when talking to different neighbors? Same for the "router" section, I think this is also a general property of NLSR. I am not sure about "hyperbolic" section, I have a strong feeling that it is also a general property.

lsa-refresh-time is required for synchronization. That section is not there anymore so it goes to general section

Hello section is there for hello protocol involving all neighbors of frequency of hello messages and hello interval is appropriately there.

Router probably can go to the general section.

But hyperbolic should remain as it is.

Have a look at the edited configuration file

Do we agree on this?

A K M Mahmudul Hoque wrote:

Hello section is there for hello protocol involving all neighbors of frequency of hello messages and hello interval is appropriately there.
Given hello is for 'all' neighbors, why it is not general?

A K M Mahmudul Hoque wrote:

Hello section is there for hello protocol involving all neighbors of frequency of hello messages and hello interval is appropriately there.

Given hello is for 'all' neighbors, why it is not general?

The hello section is more specifically for defining the behavior hello protocol.

Let me rephrase my question, does every router need to support hello protocol? does a router use hello protocol to talk to all its neighbor?
If so, then it should goes to the general section.

You can make it as a subsection in the general section if you want to make it more specific.

it does to every neighbor but it defines the more specific hello protocol's behavior

Honestly, I do not care about the layout, you can implement whatever you had.
But having a well-organized layout can make your life easier when you are writing the code.

We need to agree on the layout, do we now?

One question about configuration file layout:

How do we define section in configuration file? In other words how do we put some configuration commands under same section?

Not quite sure what is your question about... You already created sections and sections can be nested, but I think your question is about something else...

Question is how do we decide which command goes to which section?

For an example if security configuration is applicable for every neighbor or for every piece of data should we put it in general section instead of having separate section for security? Or if we have hello's configuration parameter applicable for all neighbors should we put them in general section?

This is a philosophical question and I don't have very good answer to it. We should use something that makes sense :) If something applies to the whole deamon in general, then it can go to general section.

For security, I wouldn't be sure that it belongs there, since there could be different trust models for different protocols (like sync may use one trust configuration, hello another), Yingdi may have more suggestion about this.

hello and neighbors look like they can be combined. Like, hello can go into neighbor section, symbolizing that neighbors can technically exist without being "helloed".

How does the nlsr configuration layout looks now?

Can we do some rearrangement or start working on this one?

I would at least put hello inside neighbors (there is nothing to hello without neighbors, neighbors can exist without hello, but without hello their status would be unknown), other parts look good.

May be just add hello-interval and hello-retries into neighbors section without creating a separate hello block (which always confused me). If these parameters are per-neighbor (which technically possible, I could have different quality links to different neighbors and what to set up different thresholds), then they even can go into neighbor section.

every neighbors will have same hello-interval and hello-retries.

Updated according to Alex's suggestion.

How is it now?

It looks the same as before...

Oh! Now?

now looks ok.

(from gerrit)

i just checked. you have slightly changed the config file, from what we agreed.

for one, i don't agree on change to use face-id instead of face-uri. Face-id cannot be present in config file, as it is not a stable identifier.

No I mentioned the issue in email... just temporary change.

sorry. i'm yet to catch up with all the emails...

Need to add configuration command for logging directory. User can configure the log directory

configuration command in general section:

log-dir /home/ndnuser/nlsrLog ; directory where nlsr writes log, Mandatory commands

any suggestion ?