ment at the software layer. This effect would be compounded if multiple VNFs are supported on common hardware. Thus, the separation of the hardware and software layers necessitates additional intelligence to capture and dynamically track the relationship between the layers SO that hardware faults and change management activities can be correlated with impacts on the corresponding VNFs. Of course, tracking cross-layer dependencies, correlating events across network layers, and coordinat- ing change activities across operations teams managing different network layers is something that is far from new. Technologies and processes exist and are widely used today for achieving this; how- ever, leveraging these in the network cloud will require new alarming and correlation rules/policies. Similarly, after years of driving convergence (taking functions that once resided in separate devices and combining them into a single system), there is an industry movement now reversing this trend to pursue disaggregation. Disaggregation refers to the breaking up of existing systems, where applicable, into their basic modules. Whenever possible, the disaggregated modules are implemented using standard commercial off-the-shelf servers or white box switches, and are based on open-source software. For example, a reconfigurable add-drop multiplexer (ROADM) was tra- ditionally a monolithic system provided by a single vendor with a corresponding EMS. Through disaggregation, a ROADM (also referred to as an Open ROADM in Chapter 13) may be broken up into separate transponders, wavelength selective switches and a backplane-all potentially provided by different vendors. Disaggregation promises greater flexibility, innovation, and the ability to use "best in class" for each technology. However, disaggregation also results in there being significantly more components to manage in a network, which complicates localizing and resolving issues. Just like with the separation of hardware and software, disaggregation results in more interfaces to manag