Multi Writer Issues and potential directions

September 3^rd, 2015

OvS Tables status and issues

• With random allocation and ordering of OvS tables there is no way to know
• Can random projects co-exist on a platform ?
• Will these projects have conflict at table and /or rule level ?
• Even if an agreement is struck to have specific roles to the tables (e.g. table-X = L2, table-Y = VXLAN, table-Z = NSH, table-W = L3 etc.), STILL….

there is no way to know the outcome of mixing rules from more than one project in these tables, as

• a rule in an earlier (drop, fork) or
• a rule in later (overwrite) table may have precedence

​

The Multi-writer Issues

• Every ODL project is programming Openflow tables and flow entries without considering other projects (lack of synchronization)
• Table 0 is the critical ingress table shared by all the projects, but conflict on other tables and/or order of processing and/or specific rules is possible too
• How can ODL detect rule level conflict assuming, any project is coherent but different project may collide (program for same target field/s a different action: drop or packet-in or goto_table)? (flow conflict detection)
• Different projects may use the same table ID, for different purposes (table ID conflict)
• Need for Priority?
• You can name more…

​

Proposed Requirements – for community discussion

• Manage the OvS OF tables in a way that allows foreign projects to independently program the vSwitch with known results
• Exploring options…
1. Projects:
1. Mutually exclusive on a node – i.e. separate distro = undesired outcome!
2. independent existence on a node – traversal of independent table/s (agreed classification criteria? Per flow?)
3. Interactive on a node – agreement at table and/or flow level
2. Table allocation:
• Fully canonized – Table 0 and all other tables
• Partially canonized – Table 0 only and other tables on a per project basis
• Not canonized – meaning that only cooperating projects can co-exist on a node
3. Rule level conflict: Avoid and/or Detect and/or Resolve
• Assumption: high level (i.e. NB API) policy schemes are not capable or available to deal with above issues

​

Existing Pipelines

Issue to surface the discussion is SFF control and multiple code paths emerging in ODL

5

Transport Ingress

Table 0

Path Mapper

Table 1

Path Mapper ACL

Table 2

Next Hop

Table 3

Transport Egress

Table 10

SFC

Port Security

Table 0

Ingress NAT Mapper

Table 1

Source Mapper

Table 2

Destination Mapper

Table 3

Policy Enforcer

Table 4

GBP

Egress NAT Mapper

Table 5

External Mapper

Table 6

Classifier

Table 0

Director

Table 10

Distributed ARP Responder

Table 20

DNAT

Table 30

Egress Access Control

Table 40

OVSDB

Distributed LBaaS

Table 50

Distributed Virtual Routing (DVR)

Table 60

Layer 3 forwarding

Table 70

Layer2 rewrite

Table 80

Ingress Access Control

Table 90

SNAT

Table 100

Layer2 Forwarding

Table 110

Option I: per project pipeline

• Per “flow” only one project is “selected” by table 0.
• Table ID coordination required

Option II: Stacked Pipeline

• Per “flow” multiple project in predetermined order. Every new project – reorder?
• Is there a right order? Hard to tell priority!
• Table ID coordination required

Option III: Fixed Pipeline

1. The table ID assignment is centrally coordinated (as sparse as possible) e.g. by OF Plugin
2. All the projects adhere to Table ID assignment. Every table is predefined and has specific function, for example, ACL, NAT, etc.
3. Tables are shared among projects. Every project will add flows according to table function, for example, GBP should use table 1 for Port Security, other projects should be able to add other ACL rules.
4. Per table: very strong flow conflict detection method to report any possible conflict

Classifier

Table 0

Security, ACL

Table 1

L2

Table 2

L3

Table 3

etc

Table 4

Ingress

Egress

• Per “flow” multiple project in predetermined pipeline structure e.g. OvS, NSX, OVN
• Localize collision to one table. High level Policy e.g. GBP, Intent can minimize “collisions”
• Fixed order no need to reorder per new project. Insert new functionality – simpler
• Some projects need other order?

Option IV: Branching table snippets

• Project coordination is required especially for Table ID allocation and GOTO
• Rule level conflict possible. Rule priority un clear
• Table ID coordination required

1. Allocate Tables per Project vs allocate Table per role
2. Per “flow” select one Project path OR create a predetermined “project Chain”
1. if NSH select SFC
2. If VXLAN select ovsdb
1. Pathing through multiple tables: a) apply the modifications to the packet you need and resubmit it
2. b) send it to a loopback port (does OVS have these)
3. c) actually chain the snippets

​

Option V: Openflowplugin Flow Programmer

• Merge duplicate code from every project to Openflowplugin programmer
• Every project creates its own tables per its requirement
• Every project gets unique table ID from Openflowplugin programmer
• Openflowplugin programmer uniformly manages table ID, flow ID, flow priority, flow cookie, group ID, meter ID.
• Implement flow conflict detection for every table
• Synchronize table/flow operations (lock)

GBP

SFC

OVSDB

Others…

Openflowplugin programmer

Openflowplugin

OVS₁

OVS₂

OVS_n

…

Add a middle layer

A separate project

​

Or

​

Part of openflowplugin

ofoverlay

sfcofl2

netvirt

Option VI – abandon OF tables and use Device Models

• Local rendering
• Realistic????

​

Comparison (per Project, Table, Flow requirements)

backup

AAA: Authentication, Authorization & Accounting

ALTO: Application Layer Traffic Optimization

AuthN: Authentication

BGP: Border Gateway Protocol

CAPWAP: Control and Provisioning of Wireless Access Points

COPS: Common Open Policy Service

DIDM: Device Identification and Driver management

DLUX: OpenDaylight User Experience

DDoS: Distributed Denial Of Service

DOCSIS: Data Over Cable Service Interface Specification

FRM: Forwarding Rules Manager

GBP: Group Based Policy

IoTDM: Internet of Things Data Broker

LACP: Link Aggregation Control Protocol

LISP: Locator/Identifier Separation Protocol

MAPLE: Maple Programming

NIC: Network Intent Proposal

OVSDB: Open vSwitch DataBase Protocol

OPFLEX: Extensible Policy Protocol

Legend

“LITHIUM”

OpenFlow Enabled Devices

Open vSwitches

Additional Virtual & Physical Devices

Neutron Service

SDNI

Aggregator

Persistence

L2 Switch

TCP-MD5

SXP

USC

Discovery

IoTDM

IoT

LACP

MAPLE

ALTO

CAPWAP

Reservation

TSDR

VPN Service

NIC

USC Manager

OPFLEX

Topology

Inventory

FRM

Network Applications

Orchestrations and Services

NB APIs

Applications

Plugin Services

Controller platform

SB interfaces & protocols plugins

PCEP: Path Computation Element Protocol

PCMM: Packet Cable MultiMedia

Plugin2OC: Plugin To OpenContrail

SDNI: SDN Interface (Cross-Controller Federation)

SFC: Service Function Chaining

SNBI: Secure Network Bootstrapping Infrastructure

SNMP: Simple Network Management Protocol

SXP: Source-Group Tag eXchange Protocol

TSDR: Time Series Data Repository

TTP: Table Type Patterns

USC: Unified Secure Channel

VTN: Virtual Tenant Network

15

16

17

Flowvisor/OVX Approach: Namespace/Slice

18

• Assumption: every controller must have different namespace/slice
• Namespace/Slice is a set of flows, called flowspace as well
• Flowvisor: https://github.com/OPENNETWORKINGLAB/flowvisor/wiki
• OVX (OpenVirteX): http://ovx.onlab.us/
• Partition bandwidth and flow-table

​