[Nfd-dev] comments for the nfd doc

Lan Wang (lanwang) lanwang at memphis.edu
Thu Jun 19 21:58:30 PDT 2014


On Jun 19, 2014, at 10:03 PM, Syed Obaid Amin <obaidasyed at gmail.com<mailto:obaidasyed at gmail.com>>
 wrote:




On Thu, Jun 19, 2014 at 8:50 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>> wrote:

On Jun 19, 2014, at 11:55 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

>
> On Jun 19, 2014, at 12:40 AM, Beichuan Zhang <bzhang at cs.ARIZONA.EDU<mailto:bzhang at cs.ARIZONA.EDU>>
> wrote:
>
>> Hi,
>>
>> We’ve been integrating the text of the NFD Developer’s Guide, and now it is in the final stage. Can everyone read the document or part of it, and email in comments? Any comment would be appreciated. We plan to finish it by the end of Sunday.
>>
>> The current PDF is attached. If you want the latest version, the repository is git at git.irl.cs.ucla.edu:papers/nfd-docs.git.
>>
>
> Some comments for Section 7 (Obaid please check):
>
> - "The RIB Manager that runs as a separate process, NRD (NFD RIB Daemon)" should be "NRD (NFD RIB Daemon), the RIB Manager that runs as a separate process, …"

No. I think the description is correct. The correct name is NFD RIB Manager and NRD is just an abbreviation of this, not the other way around.


> - 19 diagram should be Figure 19.
>
> - Figure 19 can be bigger and Figure 20 should be much smaller.
>
> - Figure 19 shows only NLSR.  What about other apps?  I suggest adding an app's typical interactions with NRD at the end of the time line.

Including more stuff may clutter the picture. I'm ok with including more, but just want to make sure we don't include too much.

Showing NLSR allowed me to show both self-registration (which should be same for other apps too) and prefix registration. I also think that  adding more would clutter the figure. I can add a note at "Register NLSR" step that further interactions are only valid for NLSR or other routing protocols?

OK, you can also add a note to say that other apps follow the same procedure to self-register their prefixes.



> - It's not clear what this part means: "7.7 Extending RIB Manager
> The RIB Manager currently supports only two commands { register and unregister. However, functionality of the RIB
> Manager can be extended by introducing more commands. For example, if a node needs to announce a pre x currently, it
> has to con gure the routing protocol. A set of commands for advertising and withdrawing pre xes, with the help of any
> application, could provide a more uni ed way for the operators to publish name pre xes."
>
> Isn't advertising and withdrawing prefixes supported through register and unregister already?

As I remember, withdraw and advertise were separate commands.  At least in the original protocol spec, though I already forgot what was the difference.

Yes, these two commands came from the old protocol specs. We added these commands so that NRD can talk to the routing protocols and can advertise or withdraw name prefixes through them. If I remember correctly, the motivation was to allow a unified way of publishing prefixes, instead of configuring separate routing protocols.

Now I realize that advertise/withdraw is for NRD to tell routing protocols to announce or withdraw prefixes.  These prefixes are supposed to be configured into nrd's configuration section.  This is optional as long as each routing protocol has a configuration file that allows them to do the same.  The register/unregister is for routing protocol to tell NRD to add prefixes into FIB.

Lan

Regards,
Obaid

---
Alex

> or are you saying any application should be able to advertise and withdraw prefixes.  If this is what you mean, first it's not introducing more commands.  It's just allowing regular application to issue the existing commands, right?  Also I'm not sure if it's a good to let any application do these things.
>
> Lan
>> Thanks,
>>
>> Beichuan
>>
>>
>>
>> [The attachment nfd-docs.pdf has been manually removed]
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev


_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140620/1b765154/attachment.html>


More information about the Nfd-dev mailing list