## 4 Experimental Validation  
The experimental testbed has been distributed between Telefonica and CTTC laboratory premises, as depicted in Figure 3. The testbed includes two layers, a control layer and a transport layer.  
Telefonica and CTTC deployed a control layer composed of three relevant items. First, to receive all the service requests, a Network Slice Controller was developed as part of the SDTN controller. Second, to interact with the transport domains, the testbed included Two (2) controllers, one for IP and one for Optical. To configure the routers, the IP SDN Controller used gRPC, while the Optical SDN controller used Netconf with T-API for the configuration tasks.  
The physical transport layer was composed of:  
* Two (2) 7316 Edgecore switches running ONIE.
* Two (2) Spinert traffic generator.
* Four (4) Flexi-grid DWDM nodes.  
The Edgecore used a 10 Gigabit Ethernet (10G) interface for the connection against the Spinert testers and 1G interfaces to the Optical devices. Furthermore, on each Edgecore, two (2) separate virtual routers were configured to test redundancy and route filtering between the ends. The Network Operating system (NOS) running on the virtual-routers were volta-stack deployment version 20.4-2-36-g0 ba807.  
Figure 2: Possible Network Slice instantiation in a service provider network. (**A**) Network Slice Controller as part of the hierarchical controller, (**B**) Network Slice Controller as an independent hierarchical controller, (**C**) Network Slice Controller as an independent domain controller and (**D**) Network Slice Controller as part of the domain controller.  
As we have described previously, there are several requirements for network automation for network slicing. However, a service provider can not all treat all the needs in the same way. Thus, a set of use cases were designed and executed as part of the whole testing process, the use cases were the following:  
1. Slice Creation: To request a Standards-Based and Model-Driven isolated Network Slices using. The SDTN controller would receive and translate the network slice service into specific per domain requests as follows: 1. L3 VPN service creation: In this use case, each network slice request requires an L3 VPN service creation; thus, each L3 VPN service would map to a single network slice. The endpoints defined in the slice request would map to Virtual Router and Forwarding (VRFs) instances on the virtual routers. The Yang data model used for the SDTN requests the L3 VPN services to the IP domain controller was the L3 NM [4]. 2. DWDM connectivity: The T-API [5] was used to create a new connectivity service in the transport network to enable the L2-L1 communication between the network slice endpoints. 2. Add Prefixes and destroy: The second use case expects to validate the IP connectivity between the network slices. Hence the Spirent testers announced a set of 5k IP prefixes through the prior created network slices. Afterwards, the testers make an automatic IP reachability test and a CLI route redistribution validation. Once the route propagation was validated, the testing team stopped all the Spirent prefixes' announcement, and a new automatic connectivity test was done. 3. Device recovery test: The third use case was to verify the network slices service continuity so. The testing team manually rebooted all the DCSGs. Once the devices got online again, we have checked the service status with a measurement of the service restoration time.