Comment 3 for bug 1529863

Requirement from OPNFV multisite also described here to to support this RFE:
    https://bugs.launchpad.net/neutron/+bug/1484005

    Most of telecom applications have already been designed as
    Active-Standby/Active-Active/N-Way to achieve high availability
    (99.999%, corresponds to 5.26 minutes of unplanned downtime in a year),
    typically state replication or heart beat between
    Active-Active/Active-Active/N-Way (directly or via replicated database
    services, or via private designed message format) are required.

    We have to accept the currently limited availability ( 99.99%) of a
    given OpenStack instance, and intend to provide the availability of the
    telecom application by spreading its function across multiple OpenStack
    instances.To help with this, many people appear willing to provide multiple
    “independent” OpenStack instances in a single geographic site or different sites
    , with special networking (L2/L3) connectivity between clouds.

    The telecom application often has different networking plane for different
    purpose:

    1) external network plane: using for communication with other telecom application.

    2) components inter-communication plane: one VNF often consisted of several
       components, this plane is designed for components inter-communication with
       each other

    3) backup plane: this plane is used for the heart beat or state replication
       between the component's active/standby or active/active or N-way cluster.

    4) management plane: this plane is mainly for the management purpose

    Generally these planes are separated with each other. And for legacy telecom
    application, each internal plane will have its fixed or flexible IP addressing
    plane. There are some interesting/hard requirements on the networking (L2/L3)
    between OpenStack instances, at least the backup plane across different OpenStack
    instances:

    Overlay L2 networking as the backup plane for heartbeat or state replication.
    Overlay L2 network is preferred, the reason is:

       a) Support legacy compatibility: Some telecom app with built-in internal L2
          network, for easy to move these app to virtualized telecom application, it
          would be better to provide L2 network.

       b) Support IP overlapping: multiple telecom applications may have overlapping IP
          address for cross OpenStack instance networking Therefore, over L2 networking
          across Neutron feature is required in OpenStack.