Project

General

Profile

Actions

Task #1859

closed

RIB: Need to periodically sync'up valid FaceIDs with NFD

Added by Alex Afanasyev over 9 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
RIB
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
4.00 h

Description

As it currently stands, RIB will not always have a correct knowledge about valid FaceIDs, which basically prevents registration commands to faces that existed before RIB started and faces for which notifications were missed (e.g., due to CS overflow). Also, there are cases (and I have observed) that RIB entry stays even though face is no longer exists in NFD (again, due to CS overflow).

I would suggest dropping check for valid FaceID all together. Instead of define a periodic procedure to clean up invalid FaceIDs (request all of them from NFD and then remove invalid ones from RIB).


Related issues 1 (0 open1 closed)

Has duplicate NFD - Task #1744: rib-manager: Periodically check consistency of alive facesClosedVince Lehman

Actions
Actions #1

Updated by Junxiao Shi over 9 years ago

  • Has duplicate Task #1744: rib-manager: Periodically check consistency of alive faces added
Actions #2

Updated by Junxiao Shi over 9 years ago

  • Description updated (diff)
  • Start date deleted (08/14/2014)
  • Estimated time set to 4.00 h

I agree with this proposal.

The deletion of those Routes should not trigger FIB updates, because corresponding NextHop records are already automatically deleted from FIB by NFD.

Actions #3

Updated by Davide Pesavento over 9 years ago

FWIW, I agree with this too. The whole idea of maintaining a "face table" in nrd, that needs to be kept synchronized with nfd at all times, is inherently racy and thus flawed IMHO. This also makes task #1832 unnecessary right?

By the way, I probably missed the initial design discussions about nrd, but why is it a separate process in the first place?

Actions #4

Updated by Alex Afanasyev over 9 years ago

Davide Pesavento wrote:

By the way, I probably missed the initial design discussions about nrd, but why is it a separate process in the first place?

The main objective for NRD is to be completely independent thread-wise from the forwarding. That is, all heavy calculation of FIB based on RIB needs to be done separately from NFD forwarding. Other than that objective, I don't remember other reason for it to be separate. It could have been part of NFD, but we just decided that it will be simpler to implement all NRD specific logic in a completely separate process.

Actions #5

Updated by Junxiao Shi over 9 years ago

  • Category changed from Faces to RIB
  • Status changed from New to Code review
  • Assignee set to Vince Lehman
  • Target version changed from v0.3 to v0.2
Actions #6

Updated by Davide Pesavento over 9 years ago

Alex Afanasyev wrote:

The main objective for NRD is to be completely independent thread-wise from the forwarding. That is, all heavy calculation of FIB based on RIB needs to be done separately from NFD forwarding.

Sure, a separate thread makes a lot of sense. But why implementing it as a separate process/binary then?

Actions #7

Updated by Junxiao Shi over 9 years ago

The discussion about whether RIB Daemon should be a separate process is out of the scope of this Task.
Please discuss such question in nfd-dev mailing list, thanks.

Actions #8

Updated by Junxiao Shi over 9 years ago

  • Status changed from Code review to Closed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF