Task #2635
closedRouting Table should be recalculated when Face to neighbor is destroyed
100%
Description
Currently, when the Face to a neighbor is destroyed, NLSR waits until HELLO interests timeout 3 times before rebuilding its adjacency LSA.
If a previous HELLO interest is sent and receives data back immediately before the Face is destroyed, NLSR will wait for a time close to the hello-interval
before building an adjacency LSA and recalculating its routing table.
Instead, when a Face Destroy Event is received by NLSR, it should mark the neighbor as inactive, build its adjacency LSA, and recalculate its routing table.
Updated by Alex Afanasyev almost 10 years ago
When such destroy event can happen? I'm happy with this optimization, however I'm not convinced that it is general enough. Right now we may have knowledge that face is down because we are using tunnels. Without tunnels, there are only few cases when you will be able to know that the other side is not responding or something wrong is happening (e.g., somebody is disconnecting link from the router).
Updated by Vince Lehman almost 10 years ago
Alex Afanasyev wrote:
When such destroy event can happen? I'm happy with this optimization, however I'm not convinced that it is general enough. Right now we may have knowledge that face is down because we are using tunnels. Without tunnels, there are only few cases when you will be able to know that the other side is not responding or something wrong is happening (e.g., somebody is disconnecting link from the router).
This optimization is to specifically address the case in our hyperbolic tests when NFD is killed to simulate a link failure. Each neighbor will receive a face destroy event and so can more quickly recalculate its routing table.
Updated by Lan Wang almost 10 years ago
Alex: just want to clarify -- we still have the Hello messages to detect the link/neighbor failures, so even if there's no face failure event notifications, these failures will still be detected. This patch is to handle the case when there's a face failure event notification. Previously the routing table was not immediately recalculated, which causes packet drops unnecessarily.
Updated by Alex Afanasyev almost 10 years ago
Let me say this way. I'm in no way against the change, as it will speed up routing table calculation. I just want you to be cautious using this feature in any comparison evaluations. It can be done, but with statement that this is evaluation of real link failure when routers can easily detect such event.
Updated by Lan Wang almost 10 years ago
Alex: I see your point now. There are two separate questions: (1) in real networks, are there such notifications of link failures? (2) does this optimization affect/bias any of our evaluation studies? For (1), IP networks have BFD (Bidirectional Forwarding Detection) to detect link failures. This feature is widely supported by existing hardware (http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/fs_bfd.html). NDN should have something similar, as discussed before. For (2), this optimization won't bias our comparison of hyperbolic routing and link-state routing since they share the same code logic for the most part. In the case of hyperbolic routing, it should also react to such local failure notification by immediately adjusting its RIB entries. For example, let's assume Face A and B are the best two faces to a name prefix P before the failure. If Face A fails, Hyperbolic Routing should recalculate the best two faces, say Face B and C, and update the RIB/FIB. Vince needs to double check that this is what happens in the code.
Updated by Vince Lehman almost 10 years ago
Lan Wang wrote:
Alex: I see your point now. There are two separate questions: (1) in real networks, are there such notifications of link failures? (2) does this optimization affect/bias any of our evaluation studies? For (1), IP networks have BFD (Bidirectional Forwarding Detection) to detect link failures. This feature is widely supported by existing hardware (http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/fs_bfd.html). NDN should have something similar, as discussed before. For (2), this optimization won't bias our comparison of hyperbolic routing and link-state routing since they share the same code logic for the most part. In the case of hyperbolic routing, it should also react to such local failure notification by immediately adjusting its RIB entries. For example, let's assume Face A and B are the best two faces to a name prefix P before the failure. If Face A fails, Hyperbolic Routing should recalculate the best two faces, say Face B and C, and update the RIB/FIB. Vince needs to double check that this is what happens in the code.
Yes, the code will also affect hyperbolic routing. An adjacency LSA build and routing table recalculation will be triggered by a face destroy event for both routing protocols.
Updated by Vince Lehman almost 10 years ago
- Status changed from Code review to Closed
- % Done changed from 90 to 100