To be able to identify and establish the current and needed projects' structure we need to see where we are and what we really have. Initially, the Community decided to base on Juniper proposal (2020-07-28 TWS Minutes) however this must be discussed further and fully defined. If you know there is an existing project or you think about some needed project please add the row bellow and fill up with proper information.
- Green - projects proposed by Juniper
- Red - roughly identified based on wiki pages (to be verified/archived or approved)
End to End Architecture - Yuvaraja Mariappan Sukhdev Kapur (This is an umbrella role)
Marketing Representative - Adam Grochowski
| Project | PTL contact | short description |
|---|---|---|
| Controller projects | ||
| TF Operator Framework |
| |
Config | Nagendra |
|
| Fabric & Device Management | @Ankur Tandon |
|
| Kubernetes | @Prasad Miriyala @Sachin Vaidya | |
| Control Plane | @Mahesh Sivakumar | A set of software services that maintain a model of networks and network policies, typically running on several servers for high availability. The Tungsten Fabric controller integrates with cloud management systems such as OpenStack or Kubernetes. Its function is to ensure that when a virtual machine (VM) or container is created, it is provided with network connectivity according to the network and security policies specified in the controller or orchestrator. |
Collection and Analytics |
Tungsten Fabric collects information from the cloud infrastructure (compute, network and storage) and the workloads running on it in order to facilitate operational monitoring, troubleshooting and capacity planning. The data is collected in a variety of formats such as syslogs, structured messages (known as Sandesh), Ipfix, Sflow and SNMP. Objects such as vRouters, physical hosts, virtual machines, interfaces, virtual networks and policies are modeled as User Visible Entities (UVEs) and the attributes for a UVE may come from a variety of sources in different formats. | |
| Dataplane (vRouter projects) | ||
vRouter (Dataplane) | The default deployment option today is for the vRouter forwarder to be implemented in a module that runs in the Linux kernel. The vRouter implements networking functionality that would otherwise be performed using iptables or Open vSwitch. Running in the kernel gives the forwarder direct access to network traffic as it passes through the network stack of KVM, and provides significant performance improvement over what can be achieved if the forwarder ran as a process in user space. 1) Flow setup rate improvements: | |
| vRouter Agent | @Pranava Dutta @Sangarshan P | |
The Data Plane Development Kit (DPDK), from Intel, is a set of libraries and drivers that allow applications running in user space to have direct access to a NIC without going through the KVM network stack. A version of the vRouter forwarder is available that runs in user space and supports DPDK. The DPDK vRouter provides accelerated packet throughput compared to the kernel module with unmodified VMs, and even better performance can be achieved if the guest VMs also have DPDK enabled. The DPDK vRouter works by dedicating CPU cores to packet forwarding which loop continuously waiting for packets. Not only are these cores not available for running guest VMs, as they are running at 100% continuously, and this can be an issue in some environments. 1) QoS support for DPDK vRouter: 2) IPSec support for DPDK vRouter: | ||
SR-IOV (Single Root – Input/Output Virtualization) isn’t strictly a deployment option for vRouter itself, but can be used with vRouter in some applications. SR-IOV allows the hardware resources of a NIC to be shared among multiple clients as if each has sole access, much like a hypervisor does for CPU. It gives a VM interface direct access to the NIC, so the data path bypasses the hypervisor networking stack, which leads to enhanced performance. SR-IOV can be useful when the VM is performing a gateway function between a physical network and virtual networks, but since SR-IOV involves bypassing the vRouter, the interfaces don’t participate in Tungsten Fabric virtual networks and don’t participate in network policies and network services. | ||
| Some new NICs are becoming available which are programmable. The Tungsten Fabric vRouter forwarder functionality can be implemented on these new NICs, and this brings substantial benefits in performance, particularly for small packet sizes which are dominant in some environments. Additionally, forwarding is almost completely offloaded from the x86 CPU of the server, so cores can be freed up for more VMs. Smart NICs look very promising, but obviously require that the Smart NICs are available in production environments, and it will take time for them to become in widespread use. | |
| Supporting projects | ||
| CI/CD | @Andrey Pavlov | TF CI (Jenkins) + devtools (tf-dev-env, tf-devstack, tf-dev-test) |
Deployment & Packaging | Containers and deployers layers for TF. Includes:
| |
| Documentation | The transition of existing contrail documentation to Tungsten Fabric. Develop TF documentation Will help import Contrail documentation to the upstream | |
| OpenLab | ||
| Security Vulnerability | ||
| UI | Need to identify a community representative | |