summaryrefslogtreecommitdiffstats
path: root/INFO.yaml
diff options
context:
space:
mode:
authorNeale Ranns <nranns@cisco.com>2019-11-08 12:42:31 +0000
committerOle Trøan <otroan@employees.org>2019-11-26 09:15:11 +0000
commit9db6ada779794779158163f6293b479ae7f6ad5e (patch)
tree53dd65975958b2d87b1cd312e612b45d7225e531 /INFO.yaml
parent0d3d4824a46205e776ff32c82be4cb514f459a5f (diff)
fib: Table Replace
Type: feature from the API doc, a table replace is: " The use-case is that, for some unspecified reason, the control plane has a very different set of entries it wants in the table than VPP currently has. The CP would thus like to 'replace' VPP's current table only by specifying what the new set of entries shall be, i.e. it is not going to delete anything that already eixts. the CP delcartes the start of this procedure with this begin_replace API Call, and when it has populated all the entries it wants, it calls the below end_replace API. From this point on it is of coursce free to add and delete entries as usual. The underlying mechanism by which VPP implements this replace is purposefully left unspecified. " In the FIB, the algorithm is implemented using mark and sweep. Algorithm goes: 1) replace_begin: this marks all the entries in that table as 'stale' 2) download all the entries that should be in this table - this clears the stale flag on those entries 3) signal the table converged: ip_table_replace_end - this removes all entries that are still stale this procedure can be used when an agent first connects to VPP, as an alternative to dump and diff state reconciliation. Change-Id: I168edec10cf7670866076b129ebfe6149ea8222e Signed-off-by: Neale Ranns <nranns@cisco.com>
Diffstat (limited to 'INFO.yaml')
0 files changed, 0 insertions, 0 deletions