Provide route export functionality for bgp-as-a-service sessions.

1.0 Background

Initial implementation of bgp-as-a-service was committed via bug 1518047.
It allows a tenant VM to establish BGP sessions to 2 well-known addresses,
the default gateway and DNS server, in it's subnet. This implementation had
a limitation wherein the tenant VM could advertise routes into the virtual
network that it belongs to, but it could not receive any routes. The tenant VM
was required to use a static default route with the subnet's default gateway
as the nexthop.

2.0 Overview

This blueprint is to remove the above limitation and provide route export (from
the point of view of the controller) functionality for bgp-as-a-service sessions.
The nexthop for all routes advertised to the tenant VM is set to the default
gateway address of the subnet that the tenant VM belongs to. This allows the
tenant BGP implementation to stay relatively simple by not requiring support
for recursive resolution of BGP nexthops.

3.0 Configuration Model

Existing bgp-as-a-service resource in object model is retained. Note that the
bgp-as-a-service object is associated with a virtual-machine-interface (VMI),
not simply a virtual-machine (VM). This flexibility allows a tenant VM to have
bgp sessions in multiple virtual networks if required. The implication is that
in reality a tenant VMI has bgp sessions, even though we loosely refer to a
tenant VM bgp session.

New properties are added to support additional functionality.

a. All bgp-as-a-service sessions are configured to have bidirectional exchange
of routes by default. A boolean property bgpaas-suppress-route-advertisement
allows user to emulate the v1 behavior wherein no routes are advertised to the
tenant VM.

b. If inet6 routes are being advertised to the tenant VM, they are advertised
with the v6 subnet's default gateway address as the bgp nexthop. A boolean
property bgpaas-ipv4-mapped-ipv6-nexthop causes the v4 subnet's default
gateway (in ipv4-mapped ipv6 format) to be used as the nexthop instead.

c. If multiple tenant VMs in the same virtual network have bgp-as-a-service
sessions and they use eBGP (which is mandatory in current implementation),
standard bgp as path loop prevention rules will prevent routes advertised by
one tenant VM from being advertised to other tenant VMs. A boolean field
as-override is added to existing BgpSessionAttributes property to address
this scenario. This causes the control node to replace the AS number of the
tentant VM with it's own AS number when advertising routes learnt from a
tenant VM to another tenant VM in the same virtual network. The tenant VM
does not need to implement any new functionality.

Note that bgp-as-a-service object already has a bgpaas-session-attributes
property of type BgpSessionAttributes.

4.0 Implementation

4.1 Schema Transformer Changes

Following changes are implemented:

a. The gateway-address and ipv6-gateway-address fields of BgpRouterParams
property in bgpaas client bgp-router object are set to the inet and inet6 default
gateway addresses of the inet/inet6 subnets from which the client VMI has got
addresses. This is done by default - note that this intentionally changes existing
sessions to be bidirectional.

b. The inet6-gateway-address field in BgpRouterParams bgpaas client bgp-router
object is set to the ipv4-mapped ipv6 address (instead of the actual inet6 gateway
address) if the bgpaas-ipv4-mapped-ipv6-nexthop property in bgp-as-a-service
object is set.

c. The gateway-address and ipv6-gateway-address fields are not set if the
bgpaas-suppress-route-advertisement property is set in bgp-as-a-service
object.

4.2 Control Node

Following changes are implemented:

a. Process gateway-address/ipv6-gateway-address fields in BgpRouterParams
of bgpaas client bgp-router object. Modify bgp export code to set bgp nexthops
to these addresses when advertising routes to bgp-as-a-service sessions. This
is achieved by adding a nexthop address field to the RibOut.

b. Implement as-override functionality in bgp export processing code along with
a split horizon check. The split horizon check ensures that routes advertised by
a tenant VM are not advertised back to the tenant VM even though as-override
is enabled. The intent of as-override is to advertise the routes to other tenant
VMs, not back to the originating tenant VM.

c. Strip all extended communities and non-standard attributes when exporting
routes to tenant VMs. This reduces chances of interoperability issues.

4.2 Agent

No changes are required on the vRouter agent.

Note that all routes advertised to tenant VM via BGP are already advertised to
the agent using XMPP.

5.0 Limitations

No known limitations.

6.0 Tracking

Control Node changes are tracked via bug 1552952.
Config changes are tracked via bug 1563075.
UI changes are tracked via bug 1558168.