[Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB

Lan Wang (lanwang) lanwang at memphis.edu
Tue Jun 24 22:55:19 PDT 2014


Just a couple comments:

- the rib manager already handles face closing by removing rib entries with the closed face (it subscribes to face events) .  I think if the rib manager keeps the closed face info in a list, it can check the list before generating any fib updates and directly rejects a rib update.

- the other failures can also be handled by the rib manager.  In the authentication case, it just crashes immediately.  Whatever is in the rib doesn't matter if it is going to crash anyway.  In the second case, the rib manager can try a few times too using a timer.  I discussed this with Vince before.  If it still doesn' work, just reverse the rib update (eg remove a rib entry if it was inserted).

Lan



-------- Original message --------
From: Junxiao Shi <shijunxiao at email.arizona.edu>
Date: 06/24/2014 11:34 PM (GMT-06:00)
To: "Lan Wang (lanwang)" <lanwang at memphis.edu>
Cc: Beichuan Zhang <bzhang at cs.arizona.edu>,"<nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu>
Subject: Re: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB


Dear folks

The only reasons for FIB update failures are: (a) authentication error; (b) face is closed; (c) timeouts.

  *   Authentication error (RIB Daemon's certificate is not trusted by NFD) is not recoverable, so RIB Daemon should crash.
  *   If face is closed, the whole batch is abandoned because all RIB updates in the batch are referring to a non-existent face; FIB reversing is unnecessary, because FIB will independently delete all NextHop records using the closing face.
  *   In case of a timeout, the FIB update should be retried until it succeeds or has an unrecoverable failure, or until the face is closed.

In any of the above reasons, FIB reversing is unnecessary.

Yours, Junxiao

On Wed, Jun 25, 2014 at 11:25 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Just realized one issue: if we really want to be consistent,  then we also need to reverse all fib updates that belong to the same rib update if any of them fails.  This would require keeping state of the original fib.  Also batching rib updates may make this reversal difficult if the fib updates for several rib updates to one optimal set.  There may be other complexities related to this. Just want to raise awareness.

Lan

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


More information about the Nfd-dev mailing list