[border-router] BrUlaPrefix not persisted when cli prefix add <prefix> or otBorderRouterAddOnMeshPrefix() invoked

[kangyaolei]

Describe the bug A clear and concise description of what the bug is.

• When the TBR starts, Error RoutingManager::LoadOrGenerateRandomBrUlaPrefix(void) will be invoked to load or generate the BrUlaPrefix (used as OMR prefix as my observation). If the BrUlaPrefix is a newly generated one, it will be persisted. It is fine.
• But when the user use prefix add <prefix> or invoke otError otBorderRouterAddOnMeshPrefix(otInstance *aInstance, const otBorderRouterConfig *aConfig) in code to add/update BrUlaPrefix, the BrUlaPrefix will not be persisted.
• The actual use case is, there will be the condition when a broken TBR should be replaced by a new one, but keep the running Thread Network. It is not only about the Dataset, but also about the BrUlaPrefix (or in other words, the OMR prefix). The BrUlaPrefix should be persisted when added/updated, so that it will be loaded to guarantee the new TBR to hold the exactly same Thread Network to the old one.

To Reproduce Information to reproduce the behavior, including:

• Check the BrUlaPrefix with prefix.
• Update the BrUlaPrefix with prefix add <prefix>, you can see the newly input prefix is valid.
• Reset TBR and you can see, after a power cycle, the newly input prefix disappeared, and the randomly generated prefix goes back.

Expected behavior A clear and concise description of what you expected to happen.

• When the user use prefix add <prefix> or invoke otError otBorderRouterAddOnMeshPrefix(otInstance *aInstance, const otBorderRouterConfig *aConfig) in code to add/update BrUlaPrefix, the BrUlaPrefix shoule be persisted.

Console/log output If applicable, add console/log output to help explain your problem.

Additional context Add any other context about the problem here.

[superwhd]

Could you elaborate why it is important to keep the same BrUlaPrefix while replacing the broken BR? Will there be any issues when your new BR provides a different OMR prefix?

Also, could you clarify how you'd operate to replace the BR? Are these the steps you'd expect?

1. Add the new BR into the network.
2. Add the old BR's BrUlaPrefix on the new BR.
3. Remove the old BR.

[abtink]

Thanks, @kangyaolei.

When the user uses prefix add <prefix> or invokes otError otBorderRouterAddOnMeshPrefix(otInstance *aInstance, const otBorderRouterConfig *aConfig) in code to add/update BrUlaPrefix, the BrUlaPrefix should be persisted.

This is not the desired or intended behavior. otBorderRouterAddOnMeshPrefix (cli prefix add) is not related to the RoutingManager (and otBorderRouting APIs), which manages BrUlaPrefix. It would be incorrect for it to update BrUlaPrefix.

Let me provide a short overview of the APIs and their intended behavior:

• The OT stack provides a set of low-level APIs for direct manipulation of Thread Network Data entries:
  • These include the otBorderRouter{} (in border_router.h) and otServer{} (in server.h) APIs. They allow users to add/remove on-mesh prefixes, off-mesh (external) routes, netdata services, etc., in the Thread Network Data.
  • These are flexible, low-level APIs and were present since Thread 1.0. They allow any variety of "Border Routing" to be implemented.
• Thread 1.3 introduced a standard way of implementing Thread Border Routing functionality (for residential use-cases). This specifies how a Thread BR should advertise its prefixes/routes on the infrastructure side and within the Thread mesh (e.g., defining the OMR prefix and how it is determined and published).
  • The OT stack implements this in the RoutingManager module. Its corresponding public APIs use the otBorderRouting{} name prefix (in border_routing.h). Note the difference from the low-level otBorderRouter{} name.
  • In the CLI, the commands corresponding to otBorderRouting all start with cli br {sub-command}. Check README_BR.md.
  • The idea is that when the RoutingManager functionality is enabled and used, it will manage everything and add/remove entries in the Network Data. The user would not need to use the low-level APIs to add/remove entries independently (and generally should not, as it can lead to incorrect behaviors).

The actual use case is that there will be a condition when a broken TBR should be replaced with a new one but keep the running Thread Network. It is not only about the Dataset but also about the BrUlaPrefix (or in other words, the OMR prefix). The BrUlaPrefix should be persisted when added/updated so that it will be loaded to guarantee the new TBR to hold the exactly same Thread Network as the old one.

I am not sure about this use case. If a BR is removed and a new BR is introduced, it is expected to choose its own random OMR prefix and other prefixes, the same way it will use its own (randomly picked) MAC extended address. So the expectation that it would mimic and behave exactly like the removed BR may not be valid or helpful. In general, we can have multiple BRs within a Thread mesh network; if one goes offline, another can take over (e.g., publish its OMR in Network Data).

If you still want a way to set a specific BrUlaPrefix, I suggest introducing a new API for this under otBorderRouting{} APIs and in RoutingManager.

[jwhui]

draft-ietf-snac-simple-06 Section 5.2.2 specifies the behavior for selecting a BR ULA prefix:

   In order to be able to provide addressability either on the stub
   network or on an adjacent infrastructure network, a SNAC router MUST
   allocate its own ULA Site Pefix.  ULA prefixes, described in Unique
   Local IPv6 Unicast Addresses ([RFC4193]) are randomly allocated
   prefixes.

[kangyaolei]

Thanks for the rapid response and explanation!

The general consideration is: When TBR replacement happens, the topology will be big, like 1 TBR + 16 TMEs + 100 EDs. It should be much easier for the user of TBR (like a Thread Network manager) in ethernet to access the 100 EDs with the original information, including OMR addresses.

We will have further internal discussion on it. Thanks again for your attention ~