tree aac6df566f28c13fce5c9f02275f159fab73a24d
parent 758fb8f99a7bfac3d31c419fd1a5694fc5f33f6a
author Feng Lu <lu.feng@6wind.com> 1413424356 +0800
committer Nicolas Dichtel <nicolas.dichtel@6wind.com> 1433319852 +0200

*: add VRF ID in the API message header

The API messages are used by zebra to exchange the interfaces, addresses,
routes and router-id information with its clients. To distinguish which
VRF the information belongs to, a new field "VRF ID" is added in the
message header. And hence the message version is increased to 3.

* The new field "VRF ID" in the message header:

    Length    (2 bytes)
    Marker    (1 byte)
    Version   (1 byte)
    VRF ID    (2 bytes, newly added)
    Command   (2 bytes)

  - Client side:

    - zclient_create_header() adds the VRF ID in the message header.
    - zclient_read() extracts and validates the VRF ID from the header,
      and passes the VRF ID to the callback functions registered to
      the API messages.
    - All relative functions are appended with a new parameter "vrf_id",
      including all the callback functions.
    - "vrf_id" is also added to "struct zapi_ipv4" and "struct zapi_ipv6".
      Clients need to correctly set the VRF ID when using the API
      functions zapi_ipv4_route() and zapi_ipv6_route().
    - Till now all messages sent from a client have the default VRF ID
      "0" in the header.
    - The HELLO message is special, which is used as the heart-beat of
      a client, and has no relation with VRF. The VRF ID in the HELLO
      message header will always be 0 and ignored by zebra.

  - Zebra side:

    - zserv_create_header() adds the VRF ID in the message header.
    - zebra_client_read() extracts and validates the VRF ID from the
      header, and passes the VRF ID to the functions which process
      the received messages.
    - All relative functions are appended with a new parameter "vrf_id".

* Suppress the messages in a VRF which a client does not care:

  Some clients may not care about the information in the VRF X, and
  zebra should not send the messages in the VRF X to those clients.

  Extra flags are used to indicate which VRF is registered by a client,
  and a new message ZEBRA_VRF_UNREGISTER is introduced to let a client
  can unregister a VRF when it does not need any information in that
  VRF.

  A client sends any message other than ZEBRA_VRF_UNREGISTER in a VRF
  will automatically register to that VRF.

  - lib/vrf:

    A new utility "VRF bit-map" is provided to manage the flags for
    VRFs, one bit per VRF ID.

    - Use vrf_bitmap_init()/vrf_bitmap_free() to initialize/free a
      bit-map;
    - Use vrf_bitmap_set()/vrf_bitmap_unset() to set/unset a flag
      in the given bit-map, corresponding to the given VRF ID;
    - Use vrf_bitmap_check() to test whether the flag, in the given
      bit-map and for the given VRF ID, is set.

  - Client side:

    - In "struct zclient", the following flags are changed from
      "u_char" to "vrf_bitmap_t":
          redist[ZEBRA_ROUTE_MAX]
          default_information
      These flags are extended for each VRF, and controlled by the
      clients themselves (or with the help of zclient_redistribute()
      and zclient_redistribute_default()).

  - Zebra side:

    - In "struct zserv", the following flags are changed from
      "u_char" to "vrf_bitmap_t":
          redist[ZEBRA_ROUTE_MAX]
          redist_default
          ifinfo
          ridinfo

      These flags are extended for each VRF, as the VRF registration
      flags. They are maintained on receiving a ZEBRA_XXX_ADD or
      ZEBRA_XXX_DELETE message.

      When sending an interface/address/route/router-id message in
      a VRF to a client, if the corresponding VRF registration flag
      is not set, this message will not be dropped by zebra.

    - A new function zread_vrf_unregister() is introduced to process
      the new command ZEBRA_VRF_UNREGISTER. All the VRF registration
      flags are cleared for the requested VRF.

  Those clients, who support only the default VRF, will never receive
  a message in a non-default VRF, thanks to the filter in zebra.

* New callback for the event of successful connection to zebra:

  - zclient_start() is splitted, keeping only the code of connecting
    to zebra.

  - Now zclient_init()=>zclient_connect()=>zclient_start() operations
    are purely dealing with the connection to zbera.

  - Once zebra is successfully connected, at the end of zclient_start(),
    a new callback is used to inform the client about connection.

  - Till now, in the callback of connect-to-zebra event, all clients
    send messages to zebra to request the router-id/interface/routes
    information in the default VRF.

    Of corse in future the client can do anything it wants in this
    callback. For example, it may send requests for both default VRF
    and some non-default VRFs.

Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>