doc/developer/link-state.rst

   1 Link State API Documentation
   2 ============================
   3
   4 Introduction
   5 ------------
   6
   7 The Link State (LS) API aims to provide a set of structures and functions to
   8 build and manage a Traffic Engineering Database for the various FRR daemons.
   9 This API has been designed for several use cases:
  10
  11 - BGP Link State (BGP-LS): where BGP protocol need to collect the link state
  12   information from the routing daemons (IS-IS and/or OSPF) to implement RFC7572
  13 - Path Computation Element (PCE): where path computation algorithms are based
  14   on Traffic Engineering Database
  15 - ReSerVation Protocol (RSVP): where signaling need to know the Traffic
  16   Engineering topology of the network in order to determine the path of
  17   RSVP tunnels
  18
  19 Architecture
  20 ------------
  21
  22 The main requirements from the various uses cases are as follow:
  23
  24 - Provides a set of data model and function to ease Link State information
  25   manipulation (storage, serialize, parse ...)
  26 - Ease and normalize Link State information exchange between FRR daemons
  27 - Provides database structure for Traffic Engineering Database (TED)
  28
  29 To ease Link State understanding, FRR daemons have been classified into two
  30 categories:
  31
  32 - **Consumer**: Daemons that consume Link State information e.g. BGPd
  33 - **Producer**: Daemons that are able to collect Link State information and
  34   send them to consumer daemons e.g. OSPFd IS-ISd
  35
  36 Zebra daemon, and more precisely, the ZAPI message is used to convey the Link
  37 State information between *producer* and *consumer*, but, Zebra acts as a
  38 simple pass through and does not store any Link State information. A new ZAPI
  39 **Opaque** message has been design for that purpose.
  40
  41 Each consumer and producer daemons are free to store or not Link State data and
  42 organise the information following the Traffic Engineering Database model
  43 provided by the API or any other data structure e.g. Hash, RB-tree ...
  44
  45 Link State API
  46 --------------
  47
  48 This is the low level API that allows any daemons manipulate the Link State
  49 elements that are stored in the Link State Database.
  50
  51 Data structures
  52 ^^^^^^^^^^^^^^^
  53
  54 3 types of Link State structure have been defined:
  55
  56 .. c:struct:: ls_node
  57
  58    that groups all information related to a node
  59
  60 .. c:struct:: ls_attributes
  61
  62    that groups all information related to a link
  63
  64 .. c:struct:: ls_prefix
  65
  66    that groups all information related to a prefix
  67
  68 These 3 types of structures are those handled by BGP-LS (see RFC7752) and
  69 suitable to describe a Traffic Engineering topology.
  70
  71 Each structure, in addition to the specific parameters, embed the node
  72 identifier which advertises the Link State and a bit mask as flags to
  73 indicates which parameters are valid i.e. for which the value is valid and
  74 corresponds to a Link State information conveyed by the routing protocol.
  75
  76 .. c:struct:: ls_node_id
  77
  78    defines the Node identifier as router ID IPv4 address plus the area ID for
  79    OSPF or the ISO System ID plus the IS-IS level for IS-IS.
  80
  81 Functions
  82 ^^^^^^^^^
  83
  84 A set of functions is provided to create, delete and compare Link State
  85 Node, Atribute and Prefix:
  86
  87 .. c:function:: struct ls_node *ls_node_new(struct ls_node_id adv, struct in_addr router_id, struct in6_addr router6_id)
  88 .. c:function:: struct ls_attributes *ls_attributes_new(struct ls_node_id adv, struct in_addr local, struct in6_addr local6, uint32_t local_id)
  89 .. c:function:: struct ls_prefix *ls_prefix_new(struct ls_node_id adv, struct prefix p)
  90
  91    Create respectively a new Link State Node, Attribute or Prefix.
  92    Structure is dynamically allocated. Link State Node ID (adv) is mandatory
  93    and:
  94
  95    - at least one of IPv4 or IPv6 must be provided for the router ID
  96      (router_id or router6_id) for Node
  97    - at least one of local, local6 or local_id must be provided for Attribute
  98    - prefix is mandatory for Link State Prefix.
  99
 100 .. c:function:: void ls_node_del(struct ls_node *node)
 101 .. c:function:: void ls_attributes_del(struct ls_attributes *attr)
 102 .. c:function:: void ls_prefix_del(struct ls_prefix *pref)
 103
 104    Remove, respectively Link State Node, Attributes or Prefix.
 105    Data structure is freed.
 106
 107 .. c:function:: void ls_attributes_srlg_del(struct ls_attributes *attr)
 108
 109    Remove SRLGs attribute if defined. Data structure is freed.
 110
 111 .. c:function:: int ls_node_same(struct ls_node *n1, struct ls_node *n2)
 112 .. c:function:: int ls_attributes_same(struct ls_attributes *a1, struct ls_attributes *a2)
 113 .. c:function:: int ls_prefix_same(struct ls_prefix *p1, struct ls_prefix*p2)
 114
 115    Check, respectively if two Link State Nodes, Attributes or Prefix are equal.
 116    Note that these routines have the same return value sense as '==' (which is
 117    different from a comparison).
 118
 119
 120 Link State TED
 121 --------------
 122
 123 This is the high level API that provides functions to create, update, delete a
 124 Link State Database to build a Traffic Engineering Database (TED).
 125
 126 Data Structures
 127 ^^^^^^^^^^^^^^^
 128
 129 The Traffic Engineering is modeled as a Graph in order to ease Path Computation
 130 algorithm implementation. Denoted **G(V, E)**, a graph is composed by a list of
 131 **Vertices (V)** which represents the network Node and a list of **Edges (E)**
 132 which represents Link. An additional list of **prefixes (P)** is also added and
 133 also attached to the *Vertex (V)* which advertise it.
 134
 135 *Vertex (V)* contains the list of outgoing *Edges (E)* that connect this Vertex
 136 with its direct neighbors and the list of incoming *Edges (E)* that connect
 137 the direct neighbors to this Vertex. Indeed, the *Edge (E)* is unidirectional,
 138 thus, it is necessary to add 2 Edges to model a bidirectional relation between
 139 2 Vertices. Finally, the *Vertex (V)* contains a pointer to the corresponding
 140 Link State Node.
 141
 142 *Edge (E)* contains the source and destination Vertex that this Edge
 143 is connecting and a pointer to the corresponding Link State Attributes.
 144
 145 A unique Key is used to identify both Vertices and Edges within the Graph.
 146
 147
 148 ::
 149
 150           --------------     ---------------------------    --------------
 151           | Connected  |---->| Connected Edge Va to Vb |--->| Connected  |
 152       --->|  Vertex    |     ---------------------------    |  Vertex    |---->
 153           |            |                                    |            |
 154           | - Key (Va) |                                    | - Key (Vb) |
 155       <---| - Vertex   |     ---------------------------    | - Vertex   |<----
 156           |            |<----| Connected Edge Vb to Va |<---|            |
 157           --------------     ---------------------------    --------------
 158
 159
 160 4 data structures have been defined to implement the Graph model:
 161
 162 .. c:struct:: ls_vertex
 163 .. c:struct:: ls_edge
 164 .. c:struct:: ls_ted
 165
 166  - :c:struct:`ls_prefix`
 167
 168 TED stores Vertex, Edge and Subnet elements with a RB Tree structure.
 169 The Vertex key corresponds to the Router ID for OSPF and ISO System ID for
 170 IS-IS. The Edge key corresponds to the IPv4 address, the lowest 64 bits of
 171 the IPv6 address or the combination of the local & remote ID of the interface.
 172 The Subnet key corresponds to the Prefix address (v4 or v6).
 173
 174 An additional status for Vertex, Edge and Subnet allows to determine the state
 175 of the element in the TED: UNSET, NEW, UPDATE, DELETE, SYNC, ORPHAN. Normal
 176 state is SYNC. NEW, UPDATE and DELETE are temporary state when element is
 177 processed. UNSET is normally never used and ORPHAN serves to identify elements
 178 that must be remove when TED is cleaning.
 179
 180 Vertex, Edges and Subnets management functions
 181 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 182
 183 .. c:function:: struct ls_vertex *ls_vertex_add(struct ls_ted *ted, struct ls_node *node)
 184 .. c:function:: struct ls_edge *ls_edge_add(struct ls_ted *ted, struct ls_attributes *attributes)
 185 .. c:function:: struct ls_subnet *ls_subnet_add(struct ls_ted *ted, struct ls_prefix *pref)
 186
 187    Add, respectively new Vertex, Edge or Subnet to the Link State Datebase.
 188    Vertex, Edge or Subnet are created from, respectively the Link State Node,
 189    Attribute or Prefix structure. Data structure are dynamically allocated.
 190
 191 .. c:function:: struct ls_vertex *ls_vertex_update(struct ls_ted *ted, struct ls_node *node)
 192 .. c:function:: struct ls_edge *ls_edge_update(struct ls_ted *ted, struct ls_attributes *attributes)
 193 .. c:function:: struct ls_subnet *ls_subnet_update(struct ls_ted *ted, struct ls_prefix *pref)
 194
 195    Update, respectively Vertex, Edge or Subnet with, respectively the Link
 196    State Node, Attribute or Prefix. A new data structure is created if no one
 197    corresponds to the Link State Node, Attribute or Prefix. If element already
 198    exists in the TED, its associated Link State information is replaced by the
 199    new one if there are different and the old associated Link State information
 200    is deleted and memory freed.
 201
 202 .. c:function:: void ls_vertex_del(struct ls_ted *ted, struct ls_vertex *vertex)
 203 .. c:function:: void ls_vertex_del_all(struct ls_ted *ted, struct ls_vertex *vertex)
 204 .. c:function:: void ls_edge_del(struct ls_ted *ted, struct ls_edge *edge)
 205 .. c:function:: void ls_edge_del_all(struct ls_ted *ted, struct ls_edge *edge)
 206 .. c:function:: void ls_subnet_del(struct ls_ted *ted, struct ls_subnet *subnet)
 207 .. c:function:: void ls_subnet_del_all(struct ls_ted *ted, struct ls_subnet *subnet)
 208
 209    Delete, respectively Link State Vertex, Edge or Subnet. Data structure are
 210    freed but not the associated Link State information with the simple `_del()`
 211    form of the function while the `_del_all()` version freed also associated
 212    Link State information. TED is not modified if Vertex, Edge or Subnet is
 213    NULL or not found in the Data Base. Note that references between Vertices,
 214    Edges and Subnets are removed first.
 215
 216 .. c:function:: struct ls_vertex *ls_find_vertex_by_key(struct ls_ted *ted, const uint64_t key)
 217 .. c:function:: struct ls_vertex *ls_find_vertex_by_id(struct ls_ted *ted, struct ls_node_id id)
 218
 219    Find Vertex in the TED by its unique key or its Link State Node ID.
 220    Return Vertex if found, NULL otherwise.
 221
 222 .. c:function:: struct ls_edge *ls_find_edge_by_key(struct ls_ted *ted, const uint64_t key)
 223 .. c:function:: struct ls_edge *ls_find_edge_by_source(struct ls_ted *ted, struct ls_attributes *attributes);
 224 .. c:function:: struct ls_edge *ls_find_edge_by_destination(struct ls_ted *ted, struct ls_attributes *attributes);
 225
 226    Find Edge in the Link State Data Base by its key, source or distination
 227    (local IPv4 or IPv6 address or local ID) informations of the Link State
 228    Attributes. Return Edge if found, NULL otherwise.
 229
 230 .. c:function:: struct ls_subnet *ls_find_subnet(struct ls_ted *ted, const struct prefix prefix)
 231
 232    Find Subnet in the Link State Data Base by its key, i.e. the associated
 233    prefix. Return Subnet if found, NULL otherwise.
 234
 235 .. c:function:: int ls_vertex_same(struct ls_vertex *v1, struct ls_vertex *v2)
 236 .. c:function:: int ls_edge_same(struct ls_edge *e1, struct ls_edge *e2)
 237 .. c:function:: int ls_subnet_same(struct ls_subnet *s1, struct ls_subnet *s2)
 238
 239    Check, respectively if two Vertices, Edges or Subnets are equal.
 240    Note that these routines has the same return value sense as '=='
 241    (which is different from a comparison).
 242
 243
 244 TED management functions
 245 ^^^^^^^^^^^^^^^^^^^^^^^^
 246
 247 Some helpers functions have been also provided to ease TED management:
 248
 249 .. c:function:: struct ls_ted *ls_ted_new(const uint32_t key, char *name, uint32_t asn)
 250
 251    Create a new Link State Data Base. Key must be different from 0.
 252    Name could be NULL and AS number equal to 0 if unknown.
 253
 254 .. c:function:: void ls_ted_del(struct ls_ted *ted)
 255 .. c:function:: void ls_ted_del_all(struct ls_ted *ted)
 256
 257    Delete existing Link State Data Base. Vertices, Edges, and Subnets are not
 258    removed with ls_ted_del() function while they are with ls_ted_del_all().
 259
 260 .. c:function:: void ls_connect_vertices(struct ls_vertex *src, struct ls_vertex *dst, struct ls_edge *edge)
 261
 262    Connect Source and Destination Vertices by given Edge. Only non NULL source
 263    and destination vertices are connected.
 264
 265 .. c:function:: void ls_connect(struct ls_vertex *vertex, struct ls_edge *edge, bool source)
 266 .. c:function:: void ls_disconnect(struct ls_vertex *vertex, struct ls_edge *edge, bool source)
 267
 268    Connect / Disconnect Link State Edge to the Link State Vertex which could be
 269    a Source (source = true) or a Destination (source = false) Vertex.
 270
 271 .. c:function:: void ls_disconnect_edge(struct ls_edge *edge)
 272
 273    Disconnect Link State Edge from both Source and Destination Vertex.
 274    Note that Edge is not removed but its status is marked as ORPHAN.
 275
 276 .. c:function:: void ls_vertex_clean(struct ls_ted *ted, struct ls_vertex *vertex, struct zclient *zclient)
 277
 278    Clean Vertex structure by removing all Edges and Subnets marked as ORPHAN
 279    from this vertex. Corresponding Link State Update message is sent if zclient
 280    parameter is not NULL. Note that associated Link State Attribute and Prefix
 281    are also removed and memory freed.
 282
 283 .. c:function:: void ls_ted_clean(struct ls_ted *ted)
 284
 285    Clean Link State Data Base by removing all Vertices, Edges and SubNets
 286    marked as ORPHAN. Note that associated Link State Node, Attributes and
 287    Prefix are removed too.
 288
 289 .. c:function:: void ls_show_vertex(struct ls_vertex *vertex, struct vty *vty, struct json_object *json, bool verbose)
 290 .. c:function:: void ls_show_edge(struct ls_edeg *edge, struct vty *vty, struct json_object *json, bool verbose)
 291 .. c:function:: void ls_show_subnet(struct ls_subnet *subnet, struct vty *vty, struct json_object *json, bool verbose)
 292 .. c:function:: void ls_show_vertices(struct ls_ted *ted, struct vty *vty, struct json_object *json, bool verbose)
 293 .. c:function:: void ls_show_edges(struct ls_ted *ted, struct vty *vty, struct json_object *json, bool verbose)
 294 .. c:function:: void ls_show_subnets(struct ls_ted *ted, struct vty *vty, struct json_object *json, bool verbose)
 295 .. c:function:: void ls_show_ted(struct ls_ted *ted, struct vty *vty, struct json_object *json, bool verbose)
 296
 297    Respectively, show Vertex, Edge, Subnet provided as parameter, all Vertices,
 298    all Edges, all Subnets and the whole TED if not specified. Output could be
 299    more detailed with verbose parameter for VTY output. If both JSON and VTY
 300    output are specified, JSON takes precedence over VTY.
 301
 302 .. c:function:: void ls_dump_ted(struct ls_ted *ted)
 303
 304    Dump TED information to the current logging output.
 305
 306 Link State Messages
 307 -------------------
 308
 309 This part of the API provides functions and data structure to ease the
 310 communication between the *Producer* and *Consumer* daemons.
 311
 312 Communications principles
 313 ^^^^^^^^^^^^^^^^^^^^^^^^^
 314
 315 Recent ZAPI Opaque Message is used to exchange Link State data between daemons.
 316 For that purpose, Link State API provides new functions to serialize and parse
 317 Link State information through the ZAPI Opaque message. A dedicated flag,
 318 named ZAPI_OPAQUE_FLAG_UNICAST, allows daemons to send a unicast or a multicast
 319 Opaque message and is used as follow for the Link State exchange:
 320
 321 - Multicast: To send data update to all daemons that have subscribed to the
 322   Link State Update message
 323 - Unicast: To send initial Link State information from a particular daemon. All
 324   data are send only to the daemon that request Link State Synchronisatio
 325
 326 Figure 1 below, illustrates the ZAPI Opaque message exchange between a
 327 *Producer* (an IGP like OSPF or IS-IS) and a *Consumer* (e.g. BGP). The
 328 message sequences are as follows:
 329
 330 - First, both *Producer* and *Consumer* must register to their respective ZAPI
 331   Opaque Message: **Link State Sync** for the *Producer* in order to receive
 332   Database synchronisation request from a *Consumer*, **Link State Update** for
 333   the *Consumer* in order to received any Link State update from a *Producer*.
 334   These register messages are stored by Zebra to determine to which daemon it
 335   should redistribute the ZAPI messages it receives.
 336 - Then, the *Consumer* sends a **Link State Synchronistation** request with the
 337   Multicast method in order to receive the complete Link State Database from a
 338   *Producer*. ZEBRA daemon forwards this message to any *Producer* daemons that
 339   previously registered to this message. If no *Producer* has yet registered,
 340   the request is lost. Thus, if the *Consumer* receives no response whithin a
 341   given timer, it means that no *Producer* are available right now. So, the
 342   *Consumer* must send the same request until it receives a Link State Database
 343   Synchronistation message. This behaviour is necessary as we can't control in
 344   which order daemons are started. It is up to the *Consumer* daemon to fix the
 345   timeout and the number of retry.
 346 - When a *Producer* receives a **Link State Synchronisation** request, it
 347   starts sending all elements of its own Link State Database through the
 348   **Link State Database Synchronisation** message. These messages are send with
 349   the Unicast method to avoid flooding other daemons with these elements. ZEBRA
 350   layer ensures to forward the message to the right daemon.
 351 - When a *Producer* update its Link State Database, it automatically sends a
 352   **Link State Update** message with the Multicast method. In turn, ZEBRA
 353   daemon forwards the message to all *Consumer* daemons that previously
 354   registered to this message. if no daemon is registered, the message is lost.
 355 - A daemon could unregister from the ZAPI Opaque message registry at any time.
 356   In this case, the ZEBRA daemon stops to forward any messages it receives to
 357   this daemon, even if it was previously converns.
 358
 359 ::
 360
 361        IGP                           ZEBRA                        Consumer
 362     (OSPF/IS-IS)               (ZAPI Opaque Thread)              (e.g. BGP)
 363         |                              |                             |           \
 364         |                              |      Register LS Update     |            |
 365         |                              |<----------------------------|   Register Phase
 366         |                              |                             |            |
 367         |                              |      Request LS Sync        |            |
 368         |                              |<----------------------------|            |
 369         :                              :                             :  A         |
 370         |    Register LS Sync          |                             |  |         |
 371         |----------------------------->|                             |  |        /
 372         :                              :                             :  |TimeOut
 373         :                              :                             :  |
 374         |                              |                             |  |
 375         |                              |      Request LS Sync        |  v        \
 376         |    Request LS Sync           |<----------------------------|            |
 377         |<-----------------------------|                             |   Synchronistation
 378         |    LS DB Update              |                             |           Phase
 379         |----------------------------->|      LS DB Update           |            |
 380         |                              |---------------------------->|            |
 381         |    LS DB Update (cont'd)     |                             |            |
 382         |----------------------------->|      LS DB Update (cont'd)  |            |
 383         |            .                 |---------------------------->|            |
 384         |            .                 |             .               |            |
 385         |            .                 |             .               |            |
 386         |    LS DB Update (end)        |             .               |            |
 387         |----------------------------->|      LS DB Update (end)     |            |
 388         |                              |---------------------------->|            |
 389         |                              |                             |           /
 390         :                              :                             :
 391         :                              :                             :
 392         |    LS DB Update              |                             |           \
 393         |----------------------------->|      LS DB Update           |            |
 394         |                              |---------------------------->|      Update Phase
 395         |                              |                             |            |
 396         :                              :                             :           /
 397         :                              :                             :
 398         |                              |                             |           \
 399         |                              |      Unregister LS Update   |            |
 400         |                              |<----------------------------|      Deregister Phase
 401         |                              |                             |            |
 402         |    LS DB Update              |                             |            |
 403         |----------------------------->|                             |            |
 404         |                              |                             |           /
 405         |                              |                             |
 406
 407         Figure 1: Link State messages exchange
 408
 409
 410 Data Structures
 411 ^^^^^^^^^^^^^^^
 412
 413 The Link State Message is defined to convey Link State parameters from
 414 the routing protocol (OSPF or IS-IS) to other daemons e.g. BGP.
 415
 416 .. c:struct:: ls_message
 417
 418 The structure is composed of:
 419
 420 - Event of the message:
 421
 422   - Sync: Send the whole LS DB following a request
 423   - Add: Send the a new Link State element
 424   - Update: Send an update of an existing Link State element
 425   - Delete: Indicate that the given Link State element is removed
 426
 427 - Type of Link State element: Node, Attribute or Prefix
 428 - Remote node id when known
 429 - Data: Node, Attributes or Prefix
 430
 431 A Link State Message can carry only one Link State Element (Node, Attributes
 432 of Prefix) at once, and only one Link State Message is sent through ZAPI
 433 Opaque Link State type at once.
 434
 435 Functions
 436 ^^^^^^^^^
 437
 438 .. c:function:: int ls_register(struct zclient *zclient, bool server)
 439 .. c:function:: int ls_unregister(struct zclient *zclient, bool server)
 440
 441    Register / Unregister daemon to received ZAPI Link State Opaque messages.
 442    Server must be set to true for *Producer* and to false for *Consumer*.
 443
 444 .. c:function:: int ls_request_sync(struct zclient *zclient)
 445
 446    Request initial Synchronisation to collect the whole Link State Database.
 447
 448 .. c:function:: struct ls_message *ls_parse_msg(struct stream *s)
 449
 450    Parse Link State Message from stream. Used this function once receiving a
 451    new ZAPI Opaque message of type Link State.
 452
 453 .. c:function:: void ls_delete_msg(struct ls_message *msg)
 454
 455    Delete existing message. Data structure is freed.
 456
 457 .. c:function:: int ls_send_msg(struct zclient *zclient, struct ls_message *msg, struct zapi_opaque_reg_info *dst)
 458
 459    Send Link State Message as new ZAPI Opaque message of type Link State.
 460    If destination is not NULL, message is sent as Unicast otherwise it is
 461    broadcast to all registered daemon.
 462
 463 .. c:function:: struct ls_message *ls_vertex2msg(struct ls_message *msg, struct ls_vertex *vertex)
 464 .. c:function:: struct ls_message *ls_edge2msg(struct ls_message *msg, struct ls_edge *edge)
 465 .. c:function:: struct ls_message *ls_subnet2msg(struct ls_message *msg, struct ls_subnet *subnet)
 466
 467    Create respectively a new Link State Message from a Link State Vertex, Edge
 468    or Subnet. If Link State Message is NULL, a new data structure is
 469    dynamically allocated. Note that the Vertex, Edge and Subnet status is used
 470    to determine the corresponding Link State Message event: ADD, UPDATE,
 471    DELETE, SYNC.
 472
 473 .. c:function:: int ls_msg2vertex(struct ls_ted *ted, struct ls_message *msg)
 474 .. c:function:: int ls_msg2edge(struct ls_ted *ted, struct ls_message *msg)
 475 .. c:function:: int ls_msg2subnet(struct ls_ted *ted, struct ls_message *msg)
 476
 477    Convert Link State Message respectively in Vertex, Edge or Subnet and
 478    update the Link State Database accordingly to the message event: SYNC, ADD,
 479    UPDATE or DELETE.
 480
 481 .. c:function:: struct ls_element *ls_msg2ted(struct ls_ted *ted, struct ls_message *msg, bool delete)
 482 .. c:function:: struct ls_element *ls_stream2ted(struct ls_ted *ted, struct ls_message *msg, bool delete)
 483
 484    Convert Link State Message or Stream Buffer in a Link State element (Vertex,
 485    Edge or Subnet) and update the Link State Database accordingly to the
 486    message event: SYNC, ADD, UPDATE or DELETE. The function return the generic
 487    structure ls_element that point to the Vertex, Edge or Subnet which has been
 488    added, updated or synchronous in the database. Note that the delete boolean
 489    parameter governs the action for the DELETE action: true, Link State Element
 490    is removed from the database and NULL is return. If set to false, database
 491    is not updated and the function sets the Link State Element status to
 492    Delete and return the element for futur deletion by the calling function.
 493
 494 .. c:function:: int ls_sync_ted(struct ls_ted *ted, struct zclient *zclient, struct zapi_opaque_reg_info *dst)
 495
 496    Send all the content of the Link State Data Base to the given destination.
 497    Link State content is sent is this order: Vertices, Edges then Subnet.
 498    This function must be used when a daemon request a Link State Data Base
 499    Synchronization.