[Nfd-dev] question about nrd

[Syed Obaid Amin]

Currently we don't create the fib updates as such. A few fields from
 prefix registration option received from the application are first stored
in a list and then passed to the fib as it is. If the face is invalid a
callback is called that can tell nrd that the operation was not successful.
However this status is not forwarded to the application. I can add checks
here that don't call the callback registered for successful operation until
 the whole operation is not completed. And also delete the entry from the
rib if the operation is not successful. It may work here well but not a
good solution for the next iteration as it will incur unnecessary
operations (adding a prefix entry into rib, updating corresponding entries,
creating fib updates and finally deleting this and corresponding entries
from the rib as the face was invalid). Ideally a prefix shouldn't be added
to the RIB if the associated face is invalid. This cannot be done now
as nrddoesn't have face list but it can get it later when the
notification
protocol is ready.


On Wed, Mar 12, 2014 at 9:21 PM, Lan Wang (lanwang) <lanwang at memphis.edu>wrote:

>
>  On Mar 12, 2014, at 8:18 PM, Syed Obaid Amin <obaidasyed at gmail.com>
> wrote:
>
>
>
> On Wed, Mar 12, 2014 at 7:57 PM, Alex Afanasyev <
> alexander.afanasyev at ucla.edu> wrote:
>
>>  Ok. Let's keep separate... But what should I do with the outstanding
>> commits?  Approve and submit without tests and security?  Wait for tests
>> and/or security?
>>
>>  There are other things like a broken logic---right now NRD will always
>> return status 200 success, even if command to NFD will fail.  Should this
>> be fixed before the submission?
>>
>>   We divided the nrd development in several iterations. For iteration 0,
> the one on the gerrit, nrd just translates the registration commands to the
> FibCommands. Yes much error checking is not there, especially in the part
> you mentioned, as this logic going to be changed in later iterations.
> However, if others decide I can add the error checking. Or you can merge
> the current version and error checking can be added as a separate feature.
> Again whatever the majority decides.
>
>
>  Why will the error checking change?  Since you are changing the data
> structure in the current iteration, I suppose checking the commands from
> users and the return values from nfd will be the same.
>
>  Lan
>
>
>  Regards,
>  Obaid
>
>>  ---
>> Alex
>>
>>  On Mar 12, 2014, at 5:30 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>>
>>  Logging: trivial code.
>> Command Interest verification: NRD needs more complex logic such as
>> per-namespace authorization.
>> Configuration parser: different file format.
>>
>> If NFD and NRD should be in the same repository because these three
>> modules are shared, same logic would cause NLSR to go into the same
>> repository.
>>
>> I prefer to keep them separate, because they are different programs.
>>
>> Yours, Junxiao
>>
>>
>> Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
>>>
>>> I did several iterations of updates in nrd repo, but I still have a problem with approving 2 outstanding commits.   Neither of them has unit tests, but my primary problem is lack of command interest verification, which exists now in NFD.  It doesn't make sense for me to be extremely strict in NFD and yet allow everybody to register prefixes using NRD...
>>>
>>> Also. After looking more into the code I'm less and less convinced that NRD should be in a separate repository.  A lot of things have been already implemented in NFD (logging, command interest verification, config file) and having separate repo basically means that the code needs to be copied (and maintained) in two places, instead of one.
>>>
>>> How should we proceed?
>>>
>>> ---
>>> Alex
>>>
>>>
>>> ------------------------------
>>>
>>> Nfd-dev mailing list
>>> 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
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>>
>  _______________________________________________
> Nfd-dev mailing list
> 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/20140313/6c8a2818/attachment.html>