Hi, I'm MJay from Intel. In this video, you will learn how avoid field outages and issues that can arise from your conflict of resource usage between SDN and NFV. 

How can you do this? The answer is effectively managing data plane and control plane synchronization. I'll explain how you can make the same decisions that'll not only help you succeed in the production and test phase, but also in the field. 

In the field, when met with the real traffic mix, the system can potentially face outages that can be expensive to debug. You will save money, time, and manpower by watching and following the strategic guidance given in this video. 

NFV is nothing but virtualized building blocks that are chained together to create communication services. SDN controls how this chaining is done. While NFV does the real work, SDN orchestrates and controls. 

SDN and NFV partitioning of network infrastructure requires appropriate assignments of NIC boards to system cores. Prior to introduction of SDN or NFV archtiecture, control functionality was distributed among the switch ascendings. But now, with simple and faster NICs or switches, control is managed by the SDN controller. 

System listeners tend to blindly partition the NIC or switch such that certain ports carry data plane traffic and other ports carry control traffic. Let us see why that is not workable and talk about the recommended solutions that you should follow. 

Why is simply splitting a NIC or switch at the port level not a workable solution? Because modern NICs are complex, and they share common logic among ports. 

If you split ports and assign some to control and some to data, each can program the NIC oblivious of the other models' presence. Each may operate on different ports, but since the NIC logic is common among all the ports, SDN and NFV applications might program that common logic differently, leaving the hardware in an unspecified state. This can lead to outages in network BNFs. 

So how do you solve this problem? Use the flow bifurcated model, shown here, to separate the traffic between control and data. This way, your usage model is in alignment with the design and scope of the hardware, and you have avoided models stepping on each other's toes. 

What if your use case requires you to share the NIC ports? In that case, as of version 18.05 after DPDK, you will need to install the four patches for multi-driver support in the provided links. 

We have talked about managing ports. Now let's talk about cores. As the NFVI builder, you must manage isolation of cores. 

The master core deals with the OS and control plane. DPDK cores deal with packet processing or data plane. Each has different characteristics and needs different handling. We do this by pinning the master core to the OS and isolate DPDK cores from the OS, interrupts, kernel level threads, and user level threads. 

Thanks for watching. For details on how to configure ports and cores for SDN and NFVI, read the companion article "DPDK Data Plane, Multi-Cores and Control Plane Synchronization" provided in the links.