Initially the situation described in the subject line was by design and presented no issues. However, after switching to RadixTrie as the backend for longest prefix match (LPM) there are some implications resulting in situations leading to incorrect lookup results.

Adding a subscriber for prefix A from the northbound (NB) adds a subkey with said subscriber to the RadixTrie node for that prefix, in addition to the subkey for the address (which stores the mapping). When prefix A is deleted, the subscriber entry stays on. If a southbound (SB) mapping for prefix B is added, such that B is less specific than A, a lookup for EID C, which is contained in A will return a 'null' result. That is because in the RadixTrie we have a node for A, which is the LPM for C. The mapping stored under A is 'null', since there is no address subkey, as the mapping was deleted. Even if there is a less specific mapping B from SB in the RadixTrie, that will not be returned, since the RadixTrie is agnostic to subkeys.

To avoid this, we need to delete all subkeys, when deleting a mapping. However, we can't know if a subscriber list holds entries for both NB and SB.

One option is to add subscribers to both NB and SB storage separately, but that requires composing subscribers when composing results according different NB/SB policies. This would complicate code.

I suggest we separate subscriber storage to a different SimpleMapCache structure, which holds subscribers for both NB and SB.