## 6 Discussion and Future Work  
The paradigm shift in network operation and management using SDN creates concerns regarding the proper placement of the network control plane to optimize the control of communications between data plane devices and the controller. ONOS is a dedicated distributed network operating system developed to focus the implementation of SDN in carrier-grade service provider networks. Considering the smooth and incremental deployment of SDN, SDN-IP is an application which runs on top of ONOS to enable communications between SDN and legacy networks. Similarly, the future of smart networking is considered to lie with IPv6 addressing after the depletion of IPv4 addressing. In this paper, we implemented an SDN-enabled IPv6 network using ONOS/SDN-IP to enable communications among multiple ASes in the SoDIP6 network environment, and proposed a heuristic to identify the proper location of the master ONOS controller by considering optimal path routing and the minimum control path latency. The southbound communication protocols in SDN (e.g., OpenFlow version 1.3 and beyond) support IPv6. With the migration of SDN, IPv6 addressing and routing implementations are preferable for the development of smart future networks so that all the issues of legacy networks can be avoided. Although the controller placement problem is the concern of SDN only, we considered IPv6 addressing and routing in order to encourage service providers to engage in effective joint migration planning and implementations to achieve the benefits of SoDIP6 networks. There are certain limitations to our experiment. ONOS/SDN-IP still lacks dynamic and automatic network configurations for IPv6 addressing implementation in SDN. We first implemented the use case scenario presented in Figure 4 in Mininet to verify the operation of multi-domain SoDIP6 networks with ONOS/SDN-IP implementation. Larger-size network migration implementation was not viable due to resource limits. Looking to Figure 4, all the external gateways established peering with the BGP speaker, which acted as a passive speaker. A neighbor advertisement interval of 5 s was set per peer to avoid the BGP updates flooding. However, the BGP convergence time in this scenario was negligible, because external gateways had direct peering with the BGP speaker and hence, BGP updates were not propagated through the number of hops. However, for large networks with increasing BGP broadcast traffic, the BGP speaker will be a performance bottleneck. Similarly, intent calculation takes time for SDN-IP to translate intentions into flow rules and disseminate to the data plane devices. Hence, we considered proper location for controller placement with MCPL among the BGP speaker, external gateways, and switches. Fault and failure handling with the placement of  
Figure 13: Number of requests made by switches and gateways during migration for controller placement: (**a**) Random; (**b**) Abilene; (**c**) Xeex; and (**d**) GEANT2009 networks. other controller/BGP-speakers are not within the scope of this paper. We performed the simulation of routers migration and controller placement using Python programming with a NetworkX module for migration modeling and controller placement. The gateway routers as AS gateways or CGs were randomly attached to the network nodes. In reality, the changes of number of AS gateways affects the migration time, and the controller location might be changed. The suitable placement of the SDN control plane is identified by considering the minimum control path latency using optimal path routing and BFR technique during the real-time migration of an existing legacy network into a SoDIP6 network. Our simulation results show that the BFR approach for controller placement and router migrations gave a better result than sequential router migrations in the optimal path. With the increasing number of routers migrated to SDN switches, the number of controllers required and their placement in SDN have major concerns.