Policing method to deal with Thread networks where leader is holding on to stale service entries (e.g. srp) about openthread HOT 2 OPEN

@ndyck14 the policing mechanism I have in mind is not a small/simple change and may require new text in spec and/or feature design.

The core of the idea is to try to use existing kUriServerData TMF message mechasnim where a device can send a request to leader to remove all netdata for a given RLOC16. This is used today by a parent node when one of its children is removed to request any netdata entry previously added its child to be removed. I beleice the same message/mechansim can be used to have a BR request entries added by another BR to be removed.

from openthread.

in concept, it seems straight forward: a node with updated code can observe netdata and compare it against router table. for any discrepancies, it can set some reasonable timer + jitter after which it checks again, and if the state remains, issues a command to zero the netdata for that RLOC. For now, it does not appear spec expressly prohibits this (although it does seem a slipperly slope). How long might netdata come before an updated router table (the valid case that needs to be distinguished from the otherwise invalid precipitator in #9415)?

from openthread.