Project

General

Profile

Bug #4177

Readvertise causes withdrawal of site prefix

Added by Junxiao Shi about 4 years ago. Updated 9 months ago.

Status:
Feedback
Priority:
Normal
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Steps to reproduce on NDN testbed:

  1. 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 using nfdc.
  2. 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.

#1

Updated by Nicholas Gordon about 4 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.

#2

Updated by Junxiao Shi about 4 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:

  1. Each "advertised prefix" is associated with two flags: "advertised by configuration" and "advertised by readvertise".
  2. An advertise/withdraw command from NFD-RIB's readvertise component sets/clears "advertised by readvertise" flag.
  3. Static configuration or nlsrc sets/clears "advertised by configuration" flag.
  4. If neither flag is set, the prefix is withdrawn from global routing system.
#3

Updated by Nicholas Gordon about 4 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.

#4

Updated by Junxiao Shi about 4 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.

#5

Updated by Nicholas Gordon about 4 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.

#6

Updated by Nicholas Gordon about 4 years ago

  • Status changed from New to Closed
  • Assignee set to Nicholas Gordon
  • Target version set to v0.4.0
#7

Updated by Ashlesh Gawande about 2 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).

#8

Updated by Ashlesh Gawande almost 2 years ago

  • Target version changed from Minor release v0.5.1 to Minor release v0.5.2
#9

Updated by Lan Wang almost 2 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.

#10

Updated by Lan Wang almost 2 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:

  1. Each "advertised prefix" is associated with two flags: "advertised by configuration" and "advertised by readvertise".
  2. An advertise/withdraw command from NFD-RIB's readvertise component sets/clears "advertised by readvertise" flag.
  3. Static configuration or nlsrc sets/clears "advertised by configuration" flag.
  4. 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).

#11

Updated by Lan Wang almost 2 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.

#12

Updated by Ashlesh Gawande over 1 year ago

  • Target version changed from Minor release v0.5.2 to v0.6.0
#13

Updated by Saurab Dulal 9 months ago

  • Target version changed from v0.6.0 to Minor Release v0.6.1

Also available in: Atom PDF