DGW integration with the Nuage VSD

The Nuage VSD (Virtual Services Directory) provides automation in the Nuage DC. The VSD is a programmable policy and analytics engine. It provides a flexible and hierarchical network policy framework that enables IT administrators to define and enforce resource policies.

The VSD contains a multi-tenant service directory that supports role-based administration of users, computing, and network resources. The VSD also manages network resource assignments such as IP addresses and ACLs.

To communicate with the Nuage controllers and gateways (including the 7750 SR, 7450 ESS, or 7950 XRS DGW), VSD uses an XMPP (eXtensible Messaging and Presence Protocol) communication channel. The router can receive service parameters from the Nuage VSD through XMPP and add them to the existing VPRN/VPLS service configuration.

Note: The service must be pre-provisioned in the router using the CLI, SNMP, or other supported interfaces. The VSD only pushes a limited number of parameters into the configuration. This router – VSD integration model is known as a Static-Dynamic provisioning model, because only a few parameters are dynamically pushed by VSD, as opposed to a Fully Dynamic model, where the entire service can be created dynamically by VSD.

The router – VSD integration comprises the following building blocks:

An XMPP interface to the DC XMPP server, through which the router can discover the Data Center Nuage VSDs and select a specified VSD for each VPLS/VPRN service.
The configuration of vsd-domains on those services where VSD dynamically provisions parameters. As part of the static provisioning of a service, the user configures a domain name (that is used between VSD and 7750 SR) using a new CLI command vsd-domain name. Any parameters sent by the VSD for an existing service contain the vsd-domain. Based on that tag, the router adds the required configuration changes to the correct service.
The dynamic provisioning of parameters in the following four use cases:
- L2-DOMAIN
  
  To attach a service at the gateway to a Layer 2 (Ethernet) domain in the data center with no routing at the gateway, a VPLS service should be associated with a vsd-domain of type l2-domain. When the appropriate configuration for the domain is present/added at the VSD, the VSD dynamically adds the VXLAN VNI and BGP export and import route-targets to exchange DC EVPN routes with the VPLS service.
- L2-DOMAIN-IRB
  
  To attach a service at the gateway to a Layer 2 (Ethernet) domain in the data center with routing at the gateway, an R-VPLS service should be associated with a vsd-domain of type l2-domain-irb. When the appropriate configuration for the domain is present/added at the VSD, the VSD dynamically adds the VXLAN VNI and BGP export and import route-targets to exchange DC EVPN routes with the R-VPLS service.
- VRF-GRE
  
  To attach a service at the gateway to a layer 3 domain (with GRE transport) in the data center, a VPRN service should be associated with a vsd-domain of type vrf-gre. When the appropriate configuration for the domain is present/added at the VSD, the VSD dynamically adds the BGP export and import route-targets to exchange DC IP VPN routes with the VPRN service.
- VRF-VXLAN
  
  To attach a service at the gateway to a Layer 3 domain (with VXLAN transport) in the data center, an R-VPLS service (linked to an EVPN-tunnel with ip-route-advertisement enabled) should be associated with a vsd-domain of type vrf-vxlan. When the appropriate configuration for the domain is present/added at the VSD, the VSD dynamically adds the VXLAN VNI and BGP export and import route-targets to exchange DC EVPN routes with the backhaul R-VPLS connected to the data center VPRN service.

These building blocks are described in more detail in the following subsections.