Open vSwitch Fall Conference 2018

Currently OVS-DPDK needs big memory (hugepages) and occupies some cores exclusively, but OVS kernel doesn't have such requirements, is it possible to run OVS-DPDK without hugepages, busy loop and exclusive cores? The answer is yes. DPDK can run with common 4K pages, DPDK can run in interrupt mode, this can avoid busy loop and avoid to occupy a core exclusively, OVS-DPDK will use less memory and have less cpu utilization by these ways. It will unlock developers from burdensome OVS kernel work because we mustn't maintain OVS kernel if OVS-DPDK can work well with less memory and doesn't occupy a core exclusively as OVS kernel. A workable OVS-DPDK PoC will be demonstrated during presentation.

The throughput of TCP traffic, greater than MTU size, exchanged between VMs using the OvS-DPDK datapath is significantly lower than the OvS Kernel datapath. This makes OvS-DPDK a less attractive choice for this type of use case, even though it is core for enabling NFV functions in domains that require higher throughput in TCP-based workloads, such as Telco's Service Providers.

This talk shows how TCP Segmentation Offload (TSO) is being enabled in the OvS-DPDK datapath in order to take advantage of NIC offload capabilities, to avoid segmentation inside the VM and, as a consequence, to scale the throughput in TCP-workloads between VMs. The considerations taken to achieve this will also be discussed during this talk.

Preliminary performance measurements show performance gains of 100x for traffic exchanged between VMs running on the same host and 10x for traffic exchanged between VMs running on different hosts, when compared to DPDK configurations without TSO support.

In this talk we will provide an overview of current and possible future memory management models in OVS-DPDK. We will also look at how much memory is needed and how to debug when things go wrong.

OVS now supports 2 memory models for OVS DPDK. OVS 2.9 and prior releases support ‘shared memory’ whereas OVS 2.10 also supports ‘per port memory’. Both models provide advantages and disadvantages that will be presented.

DPDK 18.05 introduced memory hotplug capability. This can allow for a more dynamic memory model approach in OVS DPDK where memory usage can grow according to requirements,

Not configuring hugepage memory correctly is a common mistake when configuring DPDK. We will talk about configuring enough hugepage memory in OVS-DPDK and debugging when you run out.

OVS kernel module has been widely used and served in various Linux distributions. Developers usually find the kernel upstream process to be time consuming, since it is generally hard to develop new features in complicated and high quality kernel code base. Moreover, in order to provide feature parity in different distributions, OVS developers constantly spend quite a lot of efforts to backport new features in upstream kernel to various distro kernels. An emerging technology, eBPF, comes into the picture as an alternative to implement OVS features in kernel which may resolve the aforementioned issues.

eBPF, extended Berkeley Packet Filter, is an expressive in-kernel virtual machine that has been included in Linux kernel since version 3.18. eBPF provides a safe and flexible way to run user provided program in the kernel on several hook points. For the network specific usage, we can load eBPF programs with tc (traffic control) and XDP (eXpress Data Path). With this technology, we can implement OVS datapath functionalities in eBPF program.

In this talk, we would like to share our exploration on the feasibility of implementing OVS datapath in eBPF through tc hook point. We first introduce the three core functionalities that handle received packets: (1) extract flow key by packet parsing; (2) flow lookup in the bpf map and (3) action executions through tail calls. Around them, we built eBPF datapath infrastructure to support bpf program loading, upcalls on flow miss, flow translation, flow installation and flow revalidate. We also highlights some of the challenges that we overcome on eBPF limitation, for example, the lack of TLV support led us to redefine a binary kernel-user API using a fixed-length array; and without a dedicated way to execute a packet, we created a dedicated device for user to kernel packet transmission, with a different BPF program attached to handle packet execute logic. Furthermore, we provide updates on our ongoing works on the megaflow and connection tracking design. Finally, we will demonstrate our eBPF datapath with VMWare’s NSX-T and OVN use cases.

Whereas previous work on the intersections of BPF and Open vSwitch focused on porting the Open vSwitch datapath to BPF, we explore the use of BPF to extend Open vSwitch with new actions, at runtime. Such extensions allow operators to customize Open vSwitch with actions that are unlikely to be eligible for upstream (e.g., tied to the operator's constraints). They also facilitate debugging (e.g., by mirroring specific packets), monitoring (via the aggregation of statistics on the switch), and experimentation of new actions and protocols.

In this presentation, after providing motivation for this work, we will discuss the integration of BPF extensions with Open vSwitch, with a focus on the impact on caching mechanisms. We will present two approaches from the academic literature, namely SoftFlow and our Oko work, as well as our more recent approach to better leverage the BPF verifier. We will illustrate each approach with evaluations and specific examples. By sharing our ideas and progress, we seek feedback from the community for future directions.

The first approach we will discuss, SoftFlow, integrates extensions as OpenFlow actions in Open vSwitch. Packet re-classifications may however be needed after each SoftFlow action that modifies packet headers. SoftFlow allows developers to set a boolean metadata value to avoid unnecessary classifications. Our first Oko prototype implements a more radical approach: by making extensions filters (OpenFlow match fields) with read-only access to packets, we remove the need for re-classifications, but severely limit use cases. In our first prototype, however, we failed to recognize the potential of the BPF verifier. Because the verifier already tracks packet writes, it can tell us whether a re-classification is needed. With this last approach, we integrate extensions as actions with read-write access to packets and transparently avoid most unnecessary classifications.

AF_XDP is a new address family aiming for high performance packet I/O. By creating an AF_XDP socket (XSK) through the socket system call, a userspace program can receive and send packets closed to the line rate. In our testbed, a micro-benchmark program shows 19Mpps for receiving and 15Mpps for transmission.

In this talk, we leverage the benefits of AF_XDP by creating a new OVS netdev type called “afxdp” and implement its configuration, packet reception, and transmit functions. Since the AF_XDP socket operates in userspace, we re-use the existing userspace datapath, dpif-netdev, and the poll-mode driver framework. With a couple of optimizations, we show that for single flow using single core, OVS dpif-netdev with afxdp can achieve 19 Mpps for receive and drop, and 14 Mpps for packet forwarding between two ports.

This talk will provide a general update on the OVS DPDK community. It will include topics such as development heat map which outlines where userspace development within the OVS code base is trending to over the past number of OVS releases. An overview of two new OVS DPDK specific branches ‘dpdk_latest’ and ‘dpdk_hwol’ recently introduced to the OVS repo will also be provided, including: requirements outlined by the community for why such branches are needed. Development process when using these branches. Relation to OVS Master and release branches.

Open source SDN is a hot topic because of its interoperability and availability in a variety of commercial solutions. Enterprise SDN customers want to learn more about Open vSwitch, and thanks to recent hardware releases such as NorthBound Network’s Zodiac FX and GX we have hardware that any homelab enthusiast can purchase. This session will explain a typical VMware administrators homelab with vSphere and NSX and how it can be integrated with a Zodiac GX, explaining how to get started with using OvS and its related ecosystem. It’s meant to be an introductory session that people new to OvS can use to get familiar but still have practical lessons learned and examples.

DPDK provides a datapath for OVS. As DPDK is a fast moving project we tie OVS versions to specific DPDK versions. The topic of which DPDK version to use for an OVS release often arises.

In this talk we'll discuss the types of DPDK releases, which ones are maintained, and the advantages and disadvantages of choosing to use DPDK LTS releases.

Openflow allows for controllers to program flow monitors in OVS / OpenFlow switch to keep track of changes happening to the flow table entries. Multiple of these flow monitors can be dynamically added, removed or modified by the controller to keep track of changes in all or a subset of flow entries. This can be useful in some use cases like auditing the flow entries between controller and OpenFlow switch or getting information about flow entries programmed by other controllers.

The presentation will cover:

* A brief introduction to this message and its purpose.

* What is currently implemented in OVS. (Nicira vendor extension vs OpenFlow 1.4+ version)

* Use cases.

* Command line support in ovs-ofctl.

With this talk, I would like to introduce the ovs_perf scripts, https://github.com/chaudron/ovs_perf, as a means of doing basic stress testing to see if your patch has a performance impact. I get a lot of feedback that people do not like the VSPerf environment due to the complexity of setting this up. This script could be run quickly on your dev environment without the huge setup burden.

The Exact Match Cache (EMC) is a per-PMD-thread lookup table which tells OVS what action to take on an incoming packet. It's purpose is to provide faster packet-processing; however, in this talk, we will show this is not always the case. We will present results which show when the EMC is a benefit and when it is a disadvantage any why this happens.

Virtual switches such as OVS perform classification for each packet, a domain where a similar procedure applies to each packet. Typically these functions are written in scalar C code for performance, however SIMD optimizations may provide higher performance. With AVX-512 the SIMD width has increased to 64-bytes, allowing 512-bits to be processed in parallel.

This talk introduces how to apply SIMD programming techniques to a vswitch such as OVS, which uses the concept of a miniflow structure to perform its switching. Specific examples of AVX-512 optimizations in the context of the OVS datapath classifier will be presented.

Port rx queues that have not been statically assigned to PMDs are currently assigned based on periodically sampled load measurements.

The assignment is performed at specific instances – port addition, port deletion, upon reassignment request via CLI etc.

It is quite possible that the traffic pattern may change after the assignment. This could lead to unbalanced load distribution among the PMDs, resulting in lower throughput.

The proposed solution is to have each PMD measure the processing load for each of its associated queues (based on processing and total cycles) every 10 seconds. If the aggregated PMD load exceeds a configured threshold for 6 consecutive intervals and if there are receive packet drops at the NIC the PMD considers itself to be overloaded.

If any PMD considers itself to be overloaded, a dry-run of the PMD assignment algorithm is performed by OVS main thread. The dry-run does NOT change the existing queue to PMD assignments.

If the resultant mapping of dry-run indicates an improved distribution of the load the actual reassignment will be performed.

The automatic rebalancing will be disabled by default and has to be enabled via configuration option. Load thresholds, improvement factor etc will also be configurable

OVS encourages network operators to innovate with more intelligent virtualization than what a L2/L3 network can provide. A production network running OVS requires a complete set of features--including vHost for connecting to VMs, connection tracking for security, LACP for link redundancy, and flexible mirroring as a few examples. This presents a challenge to hardware offload solutions as they must capture all of these features and innovations in hardware to accelerate the production system as a whole. Missing out on a key function risks forcing the network operator to choose between critical functionality and hardware-enabled efficiency.

This talk describes how to use re-programmable hardware with existing software interfaces to improve performance and lower cost without loss of functionality. This software compatibility enables migration to a hardware offloaded solution without requiring major changes to existing infrastructure.

Today’s cloud service providers want to see their CPU assets freed up from running network infrastructure software, resulting in demand for HW offloading of infrastructure components such as OVS. One key component for such an offload is a packet processing pipeline that parses, classifies, modifies and schedules packets efficiently. In addition, as the network requirements change, or new protocols emerge, the pipeline has to be reprogrammed while traffic is still flowing. This talk will focus on how we built such a pipeline inside an Intel Arria 10 FPGA. The pipeline can be reprogrammed by editing its definition in a language such as P4 or eBPF, which is then translated into hardware command tables that can be updated without interrupting the flow of traffic through the device. The SW programming and debugging tools around the pipeline will also be discussed.

Converting Open vSwitch (OVS) kernel rules to TC Flower rules has become the standard way to offload the datapath to SmartNICs and other hardware devices. Binding such TC rules to 'offloadable' ports (such as SmartNIC representers) has been shown to enable the acceleration of packet processing while saving CPU resources on the hosting server. However, one scenario not yet well defined is the case where offloadable ports are bound to a higher level Link Aggregation (LAG) netdev, such as a Linux Bond or Team device, and where this netdev is added to an OVS bridge.

This talk describes an implementation that offloads rules that either ingress or egress to a LAG device. It highlights changes made to OVS (included in v2.9) as well as to core TC code and the driver layer in the Linux kernel. Rather than introduce new features into the kernel to handle LAG offload, the design expands upon recent, independently added kernel features including the concept of TC blocks. It is shown how, with slight modification, TC blocks can be used by OVS to represent LAG devices.

OVS 2.8 added hardware offload using TC. However, Connection tracking support is still lacking. Both in TC and for hardware offload. In this talk, we'd like to present how TC API should be extended in order to use CT as an action and the ability to classify on connection state. We will also suggest necessary changes to TC and Netfiler required to support common connection tracking offload use-cases and an implementation independent of the underlying hardware.

In June of 2018 the first email from the 0-day robot went out, politely telling developers about possible areas of concern in their patches. In this talk, we'll take a look at how the robot works, and talk about future enhancements.

Tungsten Fabric, Open source version of Juniper Commercial product Contrail, it includes SDN controller (VNC - Virtual Network Controller) and vRouter, TF vRouter is similar to Open vSwitch, but vRouter is L3 network virtualization implementation, OVS is L2 network virtualization implementation, Tungsten Fabric vRouter can unify virtualized network infrastructure for hybrid multi-stack cloud, such as Openstack, OpenShift, Kubernetes, etc. This talk will compare OVS with TF vRouter from control plane, data plane to features and implementation details and help audience to understand them better from different perspectives.

In the beginning, the aim of Open vSwitch (OVS) was to meet the needs of the open source networking community to provide a feature-rich OpenFlow (OF) software switch offering a so- phisticated way to manage the underlying network of virtual machines (VMs) in Linux-based hypervisors (e.g., KVM, XEN). Due to its continuous evolution (just to mention a few: supporting standard management interfaces like NetFlow, complying with the latest OF standards, etc.), it has become the de-facto standard OF software switch implementation, recently has become the most popular network back-end for OpenStack deployments [1], and started to gain a foothold in serverless environments (e.g., OVN/Kubernetes). Although, to catch up with the industrial needs, OVS had to be as fast as possible without sacrificing its most important advantages: high programmability and generality.

To reach this end, two important parts have been introduced to the OVS forwarding plane: the "slow-path" daemon called ovs-vswitchd running in the user space, and the "fast-path" flow caching architecture running in the kernel space. In particular, the slow-path materializes the flow table, which is an ordered set of wildcard rules operating over certain header fields, and a set of packet processing primitives (i.e., actions) to be applied to matching packets. For increased flexibility, OVS permits flow rules to overlap, however this makes packet classification rather complex since, even in the case of non-overlapping flow rules, the complexity of any wildcard rule matching algorithm could be exponential [2]. On the other hand, to fasten packet classification in OVS, only the first packet of each flow is subjected to this full blown flow-table processing on the slow path, and the flow-specific rules and actions are then cached in the fast path, which can then process the rest of the flow's packets efficiently.

Since OVS 1.11, this fast path is further divided into two layers of flow caches: the microflow cache that implements a per-transport-connection exact-match store over all header fields; and the megaflow cache (MF), which, by introducing arbitrary bitwise wildcarding to the kernel space, has enabled the biggest performance improvement so far [1]. For the rest of our discussion, we will concentrate on the megaflow cache exclusively.

Since 2015, we have been investigating the highest attainable performance of OVS in many diverse use cases ranging from pure L2 forwarding to more complex telco access gateway scenarios. In some cases, we have identified some (at that time considered as) inexplicable performance drops with certain flow table entries and traffic traces even if in two measurements the use case itself was the same so did the number of flow table entries and the number of incoming flows. Then, we started to deeply analyze how the flow caching architecture of OVS works and what strategy it uses to build its data structure.

The data structure used in the MF is based on the tuple-space search (TSS) scheme: a tuple is defined for each combination of field length, and the resulted set is the "tuple space". In case of the MF, TSS means that entries matching on the same header fields are collected into a hash in which masked packet headers can be found fast. To reduce complexity, the slow path ensures that MF entries are non-overlapping, resulting in masks and associated hashes are searched sequentially until the first matching entry is found. This means that even if hash lookup is O(1), the TSS algorithm still has to iterate through all hashes assigned to different masks, rendering TSS a costly linear search when there are lots of masks. To understand how this looks like in the reality, we considered a simple Access Control List: we have a flow table with two overlapping flow rules; packets coming from the IP range 10.0.0.0/8 are allowed, and everything else should be dropped.

Key Mask Action
00001010 11111111 allow
10000000 10000000 deny
01000000 11000000 deny
ip_src action
00100000 11100000 deny
00001010 ******** ******** ******** allow
00010000 11110000 deny
******** ******** ******** ******** deny
00000000 11111000 deny
(a) Binary ACL representation of the single-field net- 00001100 11111100 deny
work policy 00001000 11111110 deny
00001011 11111111 deny
(b) Resultant non-overlapping MF
entries
Figure 1: Simple ACL and the corresponding MF cache.

The corresponding flow table shown in Fig. 1a needs to be materialized in the MF cache in a non-overlapping form. To reach this end, OVS tries to wildcard as many bits as possible to get the broadest possible rules and also reduce the required number of entries per hash tables. This strategy results in an exact-match entry for the allow-rule and 8 different key-mask pairs for testing the rest of the header bits (see Fig. 1b). Note that here we concentrated only on the relevant first 8 bits and omitted the remaining fully wildcarded 24 bits. Naturally, in order to get the above- mentioned realization in the OVS data path a corresponding packet sequence is also necessary to populate the MF cache in such a way. In essence, it means that if all incoming packets are from the 10.0.0.0/8 IP range (meaning 224 possible different IP packets), then there will only be one entry in the MF cache, which the matching can be found blazingly fast for. However, if those 8 specific packets outside of the 10.0.0.0/8 IP range are being caught by OVS (128.0/8, 64.0/8, 32.0/8, etc.), then the MF cache will end up in the above-mentioned state. Of course, even if we match on an exact /32 IP address instead of the whole /8 IP range, iterating through 32 different masks/hash tables would not cause any substantial overhead for OVS (especially, if OVS has sufficient resources, e.g., many CPU cores), yet, if we also define an ACL on another header field, say the L4 destination port, the resulting MF cache could have 32 * 16 = 512 masks/hash tables (due to the cross product), which could introduce significantly increased computation time until the matching entry is found.

To put these thoughts into numbers, we have carried out extensive performance measurements in accordance with this finding (first, in a synthetic KVM-based environment [3]), and it turned out that the tediously designed flow caching architecture offering a ludicrous speed for OVS can, in certain cases, produce the contrary: with certain flow rules and traffic patterns it can be exhausted in such a way that most of the packet classification will be done in the slow path resulting in a huge performance penalty. In particular, we found the even with 512 masks/hash tables (note again that it means 512 packets classified by 3 simple flow rules), we can slow OVS down to 10-20% of its peak performance. Moreover, if we also introduce a filtering rule on the L4 source port, it would yield 8192 masks/hash tables resulting in a performance drop to zero. Note that due to the fact that an entry (without a subsequent hit) remains "hot" in the MF cache for 10 seconds, hence the sending rate of those 8192 packets does not even need to be fast-paced: rate of less than 1000 packets/s is sufficient. This renders such a use case a covert denial-of-service attack.

During our talk, we will also carry out a live demonstration, where we will show how this technique works in our synthetic KVM-based environment, where a simple iperf traffic between two VMs will be exposed to the effects our MF cache exhaustion. We will also discuss that the restrictive access of tenants to the underlying hypervisor switches in production cloud environments (e.g., OpenStack, Kubernetes) is also sufficient to reproduce our finding revealing a possible denial- of-attack surface (note that we have recently contacted the OVS developers about this attack surface and explained all steps to reproduce such an attack). Furthermore, we will also present some immediate actions to overcome this problem, e.g., increasing the number of CPU cores available for OV

Modern cloud applications (e.g., publish-subscribe systems, streaming telemetry, database and state-machine replication, and more) frequently exhibit one-to-many communication patterns and, at the same time, require sub-millisecond latencies and high throughput. IP multicast can achieve these requirements but has control- and data-plane scalability limitations that make it challenging to offer it as a service for hundreds of thousands of tenants, typical of cloud environments. Tenants, therefore, must rely on unicast-based approaches, e.g., application-layer or overlay-based, to support multicast in their applications, imposing overhead on throughput and end-host CPU utilization, with higher and unpredictable latencies.

In this talk, we will present Elmo, a system that overcomes the data- and control-plane scalability limitations that pose a barrier to multicast deployment in public clouds. Our key insight is that emerging programmable switches and the unique characteristics of data-center topologies (namely, symmetry and the limited number of switches on any path), enable the use of efficient source-routed multicast in these cloud environments. In our approach, software switches (e.g., PISCES: a P4-enabled OVS) encode the multicast forwarding policy inside packets which are processed by hardware switches (e.g., Barefoot Tofino) at line rate. Doing so alleviates the pressure on switching hardware resources (e.g., group tables) and control-plane overhead during churn. Besides presenting the overall architecture of Elmo, we will discuss the software switch optimizations that enable Elmo's design.

In a three-tier data-center topology with 27,000 hosts, our evaluation shows that Elmo can support a million multicast groups using a 325-byte packet header; with a 20 Gbps network interface card (NIC), software switches encapsulate these headers while meeting the line-rate throughput of the link; hardware switches require as few as 1,100 multicast group-table entries on average; and the traffic overhead remains within 5% of ideal multicast.

Previous Sangfor Cloud Security Pool (CSP) used policy base routing to implement service function chaining (SFC), but that has some limitations, it can't work without help from a router, it is also not flexible enough to do some field matches, new CSP used OVS DPDK and NSH to implement service function chaining, it fixed the aforementioned limitations, it brings the below benefits to our solution: 1) Support standard NSH (IETF RFC 8300) and doesn't need NSH proxy and VNF can be NSH-unaware; 2) Reduce unnecessary NSH decap & encap to improve performance; 3) OVS DPDK improved performance; 4) Flexible field match to steer the traffic; 5) Cover various user scenarios.

In the presentation, we will introduce the previous CSP and policy based routing. Next is the new CSP with SFC. We will introduce the whole solution, including how we use OVS DPDK, NSH and ONOS. Then coms our design of SFC, how we utilize NSH and some important problems we have solved in ONOS, OVS and NSH. Finally, we will present some results about how new CSP is better than the previous one. And we may have a short video to show how to use the new CSP if time permits.

This past year has seen a tremendous growth in the use of OVN at large scale. In this talk we will examine the control plane performance of OVN a year ago vs. now. We will look at individual improvements made to OVN to make it scale to higher degrees than it had done before. We will also examine upcoming planned improvements and examine how those will continue to improve OVN's performance.

OVN by default uses Geneve encapsulation to encapsulate traffic between hypervisors on an overlay network. However, in some cases, use of Geneve is not desired. In this talk, we'll discuss why Geneve is sometimes not desired. We'll go over what facilities OVN currently has to prevent encapsulation, and we'll discuss potential future improvements to OVN to expand on the cases where encapsulation can be avoided.

OVN seems to assume that external networks are realized by a physical network, which is bridged to the logical router through a localnet port. In particular, OVN depends on ARP (and GARP) in the physical network to learn MAC bindings. However, it doesn't have to be this way. In this talk, we explore the possibility of realizing an external network as a logical switch on the overlay. This can be accomplished by using existing primitives in OVN, with a few minor modifications. We are interested in contributing our patches upstream, and working with the community to identify long-term improvements for this model.

This talk introduces forwarding group in OVN that can be used to load balance traffic across multiple ports.

The forwarding group is built using Openflow Select Group. Each bucket in the group corresponds to a logical switch port for a tunnel interface. Each bucket is also configured with a watch port to monitor the liveness of the port. In case of port down event, the corresponding bucket is not selected for traffic forwarding. This helps in fast switchover of traffic to the remaining ports in the group. For port liveness detection, BFD can be used on the tunnel interface.

Making people aware of the availability of OVS specific GDB macros, how they can be used, and how easy it is to extend them.

OVN control plane scalability is critical in production. While the distributed control plane architecture is a big advantage, the distributed controller on each hypervisor became the first bottle neck for scaling. This talk is to share how we (eBay and the community) solved the problem with Incremental Processing - the idea, challenges, and performance improvement results.

This talk will be a deep dive of how we have test and improve OVN’s scalability. We will share our methodologies of scale testing for different OVN DBs HA mechanisms like raft clustering (Active/Active) and pacemaker managed OVN DBs (Active/Standby) with and without Load balancer for which we ran scale tests. Also, a glimpse of impact on the control and data plane when testing at scale for scenarios like controller failover, whole control plane reboot, restoration, etc.

Today, Open Virtual Networking (OVN) implementation is tied with the assumption that layer 2 switches and layer 3 routers are meant for overlay networks, i.e packets always go encapsulated (using GENEVE, VXLAN or STT) in the physical network. Connectivity to end points on physical network would require gateway devices to do the conversion between overlay and physical network headers (and vice versa).

In this presentation we introduce L2/L3 networking through OVN without overlay. Packets generated from Virtual Machines (VMs) on OVN-managed OVS bridge will not be encapsulated when they go on physical network. We will present following:

a. Limitations in OVN.
b. Proposed solutions.
c. Packet flow.
d. Demo.

Policy-based routing (PBR) provides a mechanism to configure permit/deny and reroute policies on the router. Permit/deny policies are similar to OVN ACLs, but exist on the logical-router. Reroute policies are needed for service-insertion and service-chaining.

We introduced a new table in the ingress pipeline of the Logical-router, between the "IP Routing" and the "ARP/ND resolution" table. In this talk, we'll go over the following:

* Need for policy-based routing
* Why a new table in the Ingress pipeline in the logical-router
* The rationale of the location of the new table
* Demo of service-chaining using PBR

This presentation will talk about the design and implementation of encrypting OVN tunnel traffic with IPSEC.

First, we will present an OVS-IPSEC daemon which adds IPSEC support for OVS tunnels, including GRE, STT, VXLAN, and GENEVE. This daemon provides a unified and user-friendly interface to configure IPSEC tunnels with different IKE daemons (StrongSwan and LibreSwan). It also supports three authentication methods (pre-shared key, self-signed certificate, and CA-signed certificate) to meet different deployment requirements.

Then, we will explain how OVN uses OVS-IPSEC daemon to encrypt its GENEVE tunnel traffic. We will show a demo on configuring and enabling

This talk will provide an update on the Windows community around OVS and OVN.

It will cover the following topics:

- Improvements in quality of life for Windows developers such as easier ways to build the project and run unit tests (Including running Windows unit tests on Linux based environments).

- Updates on the Windows datapath. Timeline table of features that were added on Linux and still are missing on Windows.

- Future directions of the Windows datapath:

- Currently we only support creating interfaces via the Hyper-V WMI provider. This is limited because Hyper-V support needs to be enabled. Adding support for HNS networks will allow us to bypass that limitation when deploying containers.

- Adding support for TAP (WinPcap) interfaces. This will help us prepare for the future and remove our dependency on the Hyper-V vSwitch. Another hidden added benefit is that we can implement eBPF support.

- Ovn-kubernetes brief introduction and updates

- General status around Windows support in ovn-kubernetes

- How to deploy ovn-kubernetes together with Windows nodes (including Vagrant and Ansible scripts)

- Prerecorded/live demos of Openstack and ovn-kubernetes environments that have Windows nodes deployed on premise and cloud environments.