Fully-Dynamic VSD integration model

In the Static-Dynamic VSD integration model, the VPLS/VPRN service, as well as most of the parameters, must be provisioned ‟statically” through usual procedures (CLI, SNMP, and so on). VSD ‟dynamically” sends the parameters that are required for the attachment of the VPLS/VPRN service to the L2/L3 domain in the Data Center. In the Fully-Dynamic VSD integration model, the entire VPLS/VPRN service configuration is dynamically driven from VSD and no static configuration is required. Through the existing XMPP interface, the VSD provides the 7750 SR, 7450 ESS, and 7950 XRS routers with a handful of parameters that are translated into a service configuration by a python-script. This python-script provides an intermediate abstraction layer between VSD and the router, translating the VSD data model into a 7750 SR, 7450 ESS, or 7950 XRS CLI data model.

In this Fully-Dynamic integration model, the DC and DGW management entities are usually the same. The DGW operator provisions the required VPRN and VPLS services with all the parameters needed for the connectivity to the WAN and the DC. VSD pushes the required parameters so that the router can create the service completely and get it attached to an existing DC domain.

The workflow of the Fully-Dynamic integration model is shown in Figure: Fully-Dynamic VSD integration model workflow.

Figure: Fully-Dynamic VSD integration model workflow

The Fully-Dynamic VSD integration model can be summarized in the steps shown in Figure: Fully-Dynamic VSD integration model workflow and described in the following procedure:

The 7750 SR, 7450 ESS, or 7950 XRS administrator only needs to provision parameters required for connectivity to the VSD, a service-range, and configure the python script/policy in the system. Provisioning of service parameters is not required.

The service-range defines the service identifiers to include for VSD provisioned services and, when configured, they are protected from CLI changes. The vsd-policy defines the script to be used:
```
*A:PE1>config>python# info 
----------------------------------------------
        python-script "l2-domain_services" create
            primary-url "ftp://1.1.1.1/cf2/l2domain_service.py"
            no shutdown
        exit
        python-policy "py-l2" create
            description "Python script to create L2 domains"
            vsd script "l2-domain_services"
        exit
----------------------------------------------

*A:PE1>config>service>vsd# info 
----------------------------------------------
  service-range 64000 to 65000
----------------------------------------------
```
When the router boots up or the gateway configuration is changed, the router sends a message to the VSD indicating its capabilities:
- System-ID
- Name and gateway type
The VSD uses this information to register the router on its list of router GWs.

When registered, the VSD and router exchange messages where the VSD communicates its list of service-names and their domain-type to the router. Based on this list, the router sends an XMPP IQ message to request the configuration of a specified service.

The 7750 SR, 7450 ESS, or 7950 XRS router periodically audits the VSD and request a ‟DIFF” list of Full-Dynamic VSD domains. The VSD keeps a ‟DIFF” list of domains, that contains the Fully-Dynamic domain names for which the VSD has not received an IQ request from the router for a long time.

The 7750 SR, 7450 ESS, or 7950 XRS CLI user can also audit the VSD to get the DIFF list, or even the ‟FULL” list of all the domains in the VSD. The following command triggers this audit: tools perform service vsd fd-domain-sync {full | diff}.
Concurrently at the VSD, the Cloud Service Provider administrator assigns WAN resources to Enterprises defined in the VSD. In this example, a VRF-GRE domain is assigned to Enterprise-1.
Each Enterprise administrator has visibility of their own assigned WAN resource and attaches it to an existing DC Domain, assuming that both the DC domain and WAN resource are compatible. For instance, a VRF-GRE domain can only be attached to an L3 domain in the DC that uses GRE as transport.
When the Enterprise administrator attaches the service requested by the 7750 SR, 7450 ESS, or 7950 XRS router to the DC domain, the VSD sends the required configuration parameters for that service to the DGW through the XMPP channel in an IQ Service message, including:
- service name
- service type
- domain type; which can be one of the following:
  - L2-DOMAIN
  - L2-DOMAIN-IRB
  - VRF-GRE
  - VRF-VXLAN
Other required configuration parameters include:

Configuration type

static (for Static-Dynamic model) or Dynamic (for Fully-Dynamic model)

Internal route-target (RT-i)

used to export/import the BGP routes sent/received from/to the DC route-reflector

External route-target (RT-e)

used to export/import the BGP routes sent/received from/to the WAN route-reflector. The value can be the same as the RT-i.

VNI (VXLAN Network Identifier)

used to configure the EVPN-VXLAN VPLS service on the router (if the domain type is L2-DOMAIN, L2-DOMAIN-IRB, or VRF-VXLAN)

Metadata

a collection of 'opaque' <key=value> pairs including the rest of the service parameters required for the service configuration at the router
Note: The keys or values do not need to follow any specific format. The python script interprets and translates them into the router data model.

Python-policy

used by the router to find the Python script that translates the VSD parameters into configuration.
When the 7750 SR, 7450 ESS, or 7950 XRS router receives the IQ Service message, it builds a string with all the parameters and passes it to the Python module. The Python module is responsible for creating and activating the service, and, therefore, provides connectivity between the tenant domain and the WAN.

Note: The Python script cannot access all the CLI commands and nodes in the system. An allowlist of nodes and commands is built and Python only haa access to those nodes/commands. The list can be displayed using the tools dump service vsd-services command-list command.

In addition to the allowlist, the user can further restrict the allowed CLI nodes to the VSD by using a separate CLI user for the XMPP interface, and associating that user to a profile where the commands are limited. The CLI user for the XMPP interface is configurable:
```
config>system>security>cli-script>authorization>
   vsd   
[no] cli-user <username>
```
When the system executes a python-script for VSD commands, the vsd cli-user profile is checked to allow the resulting commands. A single CLI user is supported for VSD, therefore, the operator can configure a single 'profile' to restrict (even further than the allowlist) the CLI commands that can be executed by the VSD Python scripts.

No cli-user means that the system does not perform any authorization checks and the VSD scripts can access any commands that are supported in the allowlist.