The existing implementation uses a fixed timeout to clean up stale ifmap
node/link entries when the control-node connection to irond flaps. The
timer is started when the new connection is established.
The issue with using a fixed timer is that it's too conservative when the
configuration database is small and it's not sufficiently large when the
database is large. If the latter scenario happens, entries get cleaned up
prematurely, and vRouters also see premature deletion of configuration.
Proposal is to implement EndOfRib heuristics for the control-node to irond
connection as follows. Start a 5 second timer when the first PollRequest
is sent. If a PollResponse with a searchResult is received the timer is
restarted, and a new PollRequest is sent (this last part is already part
of the current state machine). Expiration of the timer triggers cleanup
of stale entries.
The reasoning here is that the heuristic only depends on the latency of a
PollRequest + PollResponse transaction, which should typically be ~50 ms.
Using a 5 second timer should ensure that we don't get false positives.
Note that the heuristic does not depend on the size of the configuration
database.
As an optimization, the timer can be expired immediately if a PollResponse
with updateResult or deleteResult is received. This indicates that there
are no more searchResults that irond has to send.
This EndOfRib heuristic can be used by control-node to determine when the
XmppServer is published to discovery. Note that this would be a separate
effort i.e. not covered by this bug.
From the TNC IFMap document:
The first time a pollResult contains search results for a new subscription, the search results MUST consist of the complete set of identifiers, links, and metadata for the subscription as specified in section 3.7.2.1. The complete search results are sent to the MAP Client in a searchResult element. Subsequent pollResults (known as “delta pollResults”) MUST contain
updates in updateResult elements as metadata is added and deletes in deleteResult elements as metadata is removed. The update Result and deleteResult elements returned by the server MUST reflect ALL of the updates which have occurred since the last poll which affect the client’s subscriptions.
A metadata change may introduce or remove a link between two subgraphs that match a subscription. When this happens after an initial searchResult message has been sent, the MAP Server informs the MAP Client about the metadata that was added or removed to the subscription using updateResult and deleteResult elements.