Bug #4177
openReadvertise causes withdrawal of site prefix
0%
Description
Steps to reproduce on NDN testbed:
- Send a prefix registration command to UCLA node for
/ndn/edu/ucla
prefix with origin=client. This command can be sent from a remote node until #2856, or it can be sent locally usingnfdc
. - Unregister the above RIB route. If the route was registered from a remote node, this can be performed by disconnecting the remote node and wait for the face to timeout.
Actual: /ndn/edu/ucla
prefix is withdrawn from the global routing system.
Expected: Static site prefixes configured in nlsr.conf
should not be withdrawn via readvertise; they can only be withdrawn by editing config or with nlsrc
command.
Updated by Nicholas Gordon over 7 years ago
This was discussed on the NDN platform call on 07-10-17:
In short, NLSR should check to see if a readvertised prefix is the same as a statically-configured one. In that case, NLSR should refuse to either advertise or withdraw a prefix.
Updated by Junxiao Shi over 7 years ago
NLSR should refuse to either advertise or withdraw a prefix.
Refusing the advertise/withdraw command would only trigger NFD-RIB to retry the command over and over.
I think the correct behavior should be:
- Each "advertised prefix" is associated with two flags: "advertised by configuration" and "advertised by readvertise".
- An advertise/withdraw command from NFD-RIB's readvertise component sets/clears "advertised by readvertise" flag.
- Static configuration or
nlsrc
sets/clears "advertised by configuration" flag. - If neither flag is set, the prefix is withdrawn from global routing system.
Updated by Nicholas Gordon over 7 years ago
Considering that Lan suggested that statically-configured should not have higher importance than others, it seems like a reasonable solution to treat these name prefixes in a similar way to how Name Prefix Table entries are treated: an entry may have multiple Routing Table entries that advertise it, indicating that this prefix is available at multiple places, so an entry is kept if at least one entry advertises it.
However, the approach of adding flags I think is not very extensible, though I can't think of a way to do it without a very heavy cost, such as a set of strings.
I can agree to using something lighter, but less extensible, like setting a vector of booleans, or a bit field.
Updated by Junxiao Shi over 7 years ago
an entry may have multiple Routing Table entries that advertise it, indicating that this prefix is available at multiple places, so an entry is kept if at least one entry advertises it.
Yes, this is correct.
the approach of adding flags I think is not very extensible
The main limitation is the inability to support multiple sources of readvertise. Consider a border router where routes received from link state routing and prefix registrations are readvertised into hyperbolic routing. It is possible that both link state routing and prefix registrations wanted to advertise the same prefix, but then link state routing withdraws this prefix. Ideally, hyperbolic should still advertise the prefix as it's needed by prefix registrations, but note-2 design would cause hyperbolic to withdraw the prefix.
If you want to avoid this limitation, each source of advertisement needs a separate flag; static config and nlsrc
are considered the same source. Then, the authentication function passed to ndn::mgmt::Dispatcher
can identify where the command comes from.
Updated by Nicholas Gordon over 7 years ago
If you're referring to a situation in which a single router serves multiple networks, which I think is the case based on your suggestion of the router handling both LS and HR, we plan to accommodate that by making multiple NLSR processes capable of running at the same time. We currently enforce that only one kind of routing (HR or LS) can be used by an NLSR process.
Given our strategy, it won't be necessary to differentiate between different sources of readvertise.
Updated by Nicholas Gordon about 7 years ago
- Status changed from New to Closed
- Assignee set to Nicholas Gordon
- Target version set to v0.4.0
Updated by Ashlesh Gawande about 5 years ago
- Status changed from Closed to Feedback
- Target version changed from v0.4.0 to Minor release v0.5.1
- Start date deleted (
07/09/2017)
Don't see sources being used anywhere in the code (no insert call provides source).
Updated by Ashlesh Gawande about 5 years ago
- Target version changed from Minor release v0.5.1 to Minor release v0.5.2
Updated by Lan Wang about 5 years ago
Ashlesh Gawande wrote:
Don't see sources being used anywhere in the code (no insert call provides source).
The sources should be used to check whether a prefix should be advertised or withdrawn.
Updated by Lan Wang about 5 years ago
Junxiao Shi wrote:
NLSR should refuse to either advertise or withdraw a prefix.
Refusing the advertise/withdraw command would only trigger NFD-RIB to retry the command over and over.
I think the correct behavior should be:
- Each "advertised prefix" is associated with two flags: "advertised by configuration" and "advertised by readvertise".
- An advertise/withdraw command from NFD-RIB's readvertise component sets/clears "advertised by readvertise" flag.
- Static configuration or
nlsrc
sets/clears "advertised by configuration" flag.- If neither flag is set, the prefix is withdrawn from global routing system.
The command should not be refused. Instead, the command should be accepted and given a corresponding reply (if the prefix is already advertised, then say so).
Updated by Lan Wang about 5 years ago
Each prefix should be associated with a set of sources. When a command to advertise a prefix is received, that source is added to the set and the prefix will be advertised if it has not been advertised. When a command to withdraw the prefix is received, that source is removed from the set and, as long as there is one source left, do nothing. Otherwise, withdraw the prefix.
Updated by Ashlesh Gawande almost 5 years ago
- Target version changed from Minor release v0.5.2 to v0.6.0
Updated by Saurab Dulal almost 4 years ago
- Target version changed from v0.6.0 to Minor Release v0.6.1